Internet Tools (InfoMagic)/Internet Tools.iso/dos_win/winsock/wsock20/archive

Internet Message Format | 1994-05-03 | 139KB

From sunsite.unc.edu!winsock-hackers Tue Oct 26 22:37:12 1993
Date: Wed, 27 Oct 93 01:37:51 EDT
Message-Id: <9310262311.AA01246@atlas>
Reply-To: [e-mail]
Originator: [e-mail]
Sender: [e-mail]
From: [e-mail]
To: Multiple recipients of list <[e-mail]>
Subject: Re: gethostname().
X-Listprocessor-Version: 6.0a -- ListProcessor by Anastasios Kotsikonas
Status: OR

Thus expounded Distinct TCP/IP on Oct 25,10:22pm:
/--------------------
|Hi!
|
|The WINSOCK spec says that gethostname() returns a name that is
|"guaranteed" to be successfully parsed by gethostbyname(). This
|effectively means that gethostname() cannot return an internet
|address in the formatt "a.b.c.d", because these are not parsed by
|gethostbyname().
|
|If a machine is getting its local IP address from RARP, BOOTP
|or PPP, it only has a valid IP address and no name associated
|with it. So in these case what should gethostname() return?
|It cannot return the IP address and somehow returning an error
|code does not seem to be the correct option. If it has to return an
|error, what error code should it return?????

There is a broader issue - what if the stack is configured with a
name, but that name is not in the stacks host table or the DNS - in that
case, normal processing would NOT resolve the name into an IP number.

This gethostname() is usually used to find the stack's IP number,
by calling gethostbyname() on the string returned by gethostname().

My feeling is the stack should provide some sort of dummy name if there
is not one coded, and the gethostbyname/WSAgetHostByName should explicitly
check for this string and return the local IP number, without going
through the normal resolving process. That way, if RARP/BOOTP/etc is
used to configure the IP number and there is no host name, gethostname
should return "localhost" or something that only need be meaningful
to the stack without recourse to the DNS or hosts file.

Its a good question, that needs further clarification in the next
spec..

|    vikas
|
|==========================================================
|Vikas Garg                   Phone : [phone]
|Distinct Corp.               Fax   : [phone]
|14395 Saratoga Av.           E-Mail: [e-mail]
|Saratoga, CA 95070
|U.S.A.
|==========================================================
|
\--------------------- {end}


--
Paul Brooks              |[e-mail]       |Emerging Standard:
TurboSoft Pty Ltd        |[e-mail]|  one that has not yet
579 Harris St., Ultimo   |                         |  been superseded.
Sydney Australia 2007    |ph: [phone]       |
????
????
From gabor.inference.com!inference.com!gloster Thu Jan 27 13:46:00 1994
Date: Thu, 27 Jan 94 13:50:20 PST
From: "Vance M. Gloster" <[e-mail]>
Message-Id: <9401272150.AA09238@quaestor>
To: [e-mail]
Subject: Windows Sockets 2 Contribution
content-length: 137
Status: OR

UDP sockets

Adding a standard interface to UDP sockets so that a standard Ping
could be created.

-Vance Gloster
 [e-mail]
????
????
From gabor.inference.com!inference.com!gloster Thu Jan 27 13:48:34 1994
Date: Thu, 27 Jan 94 13:53:00 PST
From: "Vance M. Gloster" <[e-mail]>
Message-Id: <9401272153.AA09283@quaestor>
To: [e-mail]
Subject: Windows Sockets 2 Contribution
content-length: 231
Status: OR

BOOTP support

Explicit support for BOOTP which allows dialup connections to set
their IP address dynamically at connection time.  A standard interface
for this should be explicitly required.

-Vance Gloster
 [e-mail]
????
????
From gabor.inference.com!inference.com!gloster Thu Jan 27 14:33:48 1994
Date: Thu, 27 Jan 94 14:39:21 PST
From: "Vance M. Gloster" <[e-mail]>
Message-Id: <9401272239.AA11350@quaestor>
To: [e-mail]
Subject: Windows Sockets 2 Contribution
content-length: 379
Status: OR

Custom wrapper creation.

As discussions on the winsock maillist have indicated, creating a DLL
that would provide easy access to winsock from another language (i.e.,
Visual BASIC) is both desirable and difficult to do portably on
Winsock 1.1.  The 2.0 product should explicitly support creating
portable layers on top of Winsock in a DLL.

-Vance Gloster
 [e-mail]
????
????
From relay2.uu.net!uunet.uu.net!tcemail!is3.indy.tce.com!fisherm Fri Jan 28
10:37:33 1994
Reply-To: tcemail![e-mail]
Return-Receipt-To: tcemail!is3.indy.tce.com![e-mail]
Date: Fri, 28 Jan 94 13:23:00 PST
From: Fisher Mark <tcemail!is3.indy.tce.com![e-mail]>
Subject: WinSock 2.0 -- Raw Sockets for Ping
To: "Windows Sockets 2.0" <[e-mail]>
Message-Id: <[e-mail]>
Encoding: 12 TEXT
X-Mailer: Microsoft Mail V3.0
Status: OR


The most needed item is mandatory raw sockets support to the level required
by ping.  Ping is what everyone uses for initial testing of connections --
it should always be able to be written for a conforming WinSock
implementation.
======================================================================
Mark Fisher                            Thomson Consumer Electronics
[e-mail]           Indianapolis, IN

"Just as you should not underestimate the bandwidth of a station wagon
traveling 65 mph filled with 8mm tapes, you should not overestimate
the bandwidth of FTP by mail."
????
????
From chaos.tci.com!klaven.tci.com!jspoffor Mon Jan 31 14:49:55 1994
Message-Id: <[e-mail]>
From: jspoffor <[e-mail]>
Date: Mon, 31 Jan 94 15:50
To: martinh <[e-mail]>
Subject: Other Protocols in Winsock 2.0
Status: OR


I'd really like to see the inclusion of other protocols, and if I had to
pick only one, I'd say add IPX/SPX.  Perhaps it wouldn't be manditory, but
there should be some way of determining if it supports IPX/SPX (as opposed
to TCP/IP) at start up time.  Also, the necessary structures and control
differences would need to be included in the specification.  Right now, I
have to add my own abstraction layer to deal with doing SNMP over IPX or IP.
 It would be great not to need to do that.

Jason Spofford
[e-mail]

????
????
From chaos.tci.com!klaven.tci.com!jspoffor Mon Jan 31 14:51:43 1994
Message-Id: <[e-mail]>
From: jspoffor <[e-mail]>
Date: Mon, 31 Jan 94 15:50
To: martinh <[e-mail]>
Subject: SLIP and CSLIP in Winsock 2.0
Status: OR


It would be great if there was a standard way to support SLIP and CSLIP
through Winsock.

Jason Spofford
[e-mail]

????
????
From chaos.tci.com!klaven.tci.com!jspoffor Mon Jan 31 14:51:43 1994
Message-Id: <[e-mail]>
From: jspoffor <[e-mail]>
Date: Mon, 31 Jan 94 15:50
To: martinh <[e-mail]>
Subject: RAW SOCKETS in Winsock 2.0
Status: OR


I'm an application developer.  I'd like winsock implementations to have to
support PING  by providing access to ICMP (i.e. RAW SOCKETS).  I'm sure you
have  heard this before, I'd just like to add my voice.

????
????
From relay2.pipex.net!firefox.co.uk!marke Wed Feb  2 03:45:26 1994
From: Mark Edwards <[e-mail]>
X-Mailer: SCO System V Mail (version 3.2)
To: [e-mail]
Subject: Windows Sockets 2 Contribution
Date: Wed, 2 Feb 94 11:11:10 gmt
Message-ID: <[e-mail]>
Status: OR

Hi Martin,

Long time no see, hope all is well.

Item 1.

Short Desc: Winsock 2 requires the capability for Multi-protocol support.

Longer Desc: This is reasonably easy to provide, since all the DLL needs do
is communicate to the correct stack by checking the protocol family passed
in the socket() call.  It would probably, be a good idea to include an
area in the WSADATA structure that holds the values of the protocol families
that the DLL currently knows about and can handle.  This is not important
to stack vendors who only produce one stack, but affects vendors such as
Microsoft, JSB and Firefox.


Regards,
Mark.

-------------------------------------------------------------------------
Mark S. Edwards
Firefox Communications Ltd,
Cranmore House,
Cranmore Boulevard,
Solihull, West Midlands. United Kingdom. B90 4RX.

phone:  [phone] (intl, 44 21 609 6090)
Fax  :  [phone] (intl, 44 21 609 6060)

Internet: [e-mail]
-------------------------------------------------------------------------
????
????
From relay2.pipex.net!firefox.co.uk!marke Wed Feb  2 03:46:34 1994
From: Mark Edwards <[e-mail]>
X-Mailer: SCO System V Mail (version 3.2)
To: [e-mail]
Subject: Windows Sockets 2 Contribution
Date: Wed, 2 Feb 94 11:12:24 gmt
Message-ID: <[e-mail]>
Status: OR

Martin,

Item 2.

Short Desc: A mechanism for retrieving Service definitions from a network.

Longer Desc: Sockets as it stands is great for protocols where the address
information is known by the application or entered by the user.  It cannot
cope with broadcast service definitions where the user has no idea of the
network address. The means for retrieving service definitions from a
network is required for protocols such as DEC LAT, IPX/SPX (SAP) and, dare
I say it, Firefox.  We have currently implemented such a mechanism, and
think that it shows promise as a generic 'Extra functionality' handler.



Regards,
Mark.

-------------------------------------------------------------------------
Mark S. Edwards
Firefox Communications Ltd,
Cranmore House,
Cranmore Boulevard,
Solihull, West Midlands. United Kingdom. B90 4RX.

phone:  [phone] (intl, 44 21 609 6090)
Fax  :  [phone] (intl, 44 21 609 6060)

Internet: [e-mail]
-------------------------------------------------------------------------
????
????
From relay2.pipex.net!firefox.co.uk!marke Wed Feb  2 03:47:57 1994
From: Mark Edwards <[e-mail]>
X-Mailer: SCO System V Mail (version 3.2)
To: [e-mail]
Subject: Windows Sockets 2 Contribution
Date: Wed, 2 Feb 94 11:13:45 gmt
Message-ID: <[e-mail]>
Status: OR

Martin,

Item 3.

Short Desc: A clearing house for new protocol families and associated
address types.

Longer Desc: Firefox at the moment have implemented a protocol family with
an address structure.  The protocol family is obviously chosen at random
and at the moment conflicts with nobody else.  If vendors are encouraged
to add new protocol types then we need to ensure that the protocol family
numbers do not clash.



Regards,
Mark.

-------------------------------------------------------------------------
Mark S. Edwards
Firefox Communications Ltd,
Cranmore House,
Cranmore Boulevard,
Solihull, West Midlands. United Kingdom. B90 4RX.

phone:  [phone] (intl, 44 21 609 6090)
Fax  :  [phone] (intl, 44 21 609 6060)

Internet: [e-mail]
-------------------------------------------------------------------------
????
????
From relay2.pipex.net!firefox.co.uk!marke Wed Feb  2 03:49:26 1994
From: Mark Edwards <[e-mail]>
X-Mailer: SCO System V Mail (version 3.2)
To: [e-mail]
Subject: Windows Sockets 2 Contribution
Date: Wed, 2 Feb 94 11:15:10 gmt
Message-ID: <[e-mail]>
Status: OR

Martin,

Item 4.

Short Desc: A mechanism for broadcasting service definitions on a network.

Longer Desc: If Winsock 2 caters for the retrieval of broadcast service
definitions, then it should also be capable of accepting a service definition
from an application to be broadcast on the network.


Regards,
Mark.

-------------------------------------------------------------------------
Mark S. Edwards
Firefox Communications Ltd,
Cranmore House,
Cranmore Boulevard,
Solihull, West Midlands. United Kingdom. B90 4RX.

phone:  [phone] (intl, 44 21 609 6090)
Fax  :  [phone] (intl, 44 21 609 6060)

Internet: [e-mail]
-------------------------------------------------------------------------
????
????
From sun.com!suneast.east.sun.com!rwolin Wed Feb  2 14:11:08 1994
Date: Wed, 2 Feb 1994 17:16:48 +0500
From: Ross Wolin - PC Networking Engineering CONTRACTOR
<[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Windows Sockets 2 Contribution
Content-Length: 378
Status: OR


Callback procedures for asynchronous sockets.

Currently asynchronous sockets notify processes of socket events
by sending a Window message.  I would like to see asynchronous
socket have the option to call a callback routine OR send a
window message.  This functionality would make asynchronous C++
socket objects work much better...


Ross Wolin
[e-mail]
"Ni!"
????
????
From calypso-2.oit.unc.edu!winsock-hackers Mon Feb  7 15:46:59 1994
Date: Mon, 7 Feb 1994 18:39:36 -0500
Message-Id: <9402072350.AA04134@atlas>
Reply-To: [e-mail]
Originator: [e-mail]
Sender: [e-mail]
From: [e-mail]
To: Multiple recipients of list <[e-mail]>
Subject: Winsock v2
X-Listprocessor-Version: 6.0a -- ListProcessor by Anastasios Kotsikonas
Status: ORP
History: Replied to on 18 Feb 94

So we're well into the new year. Is discussion of features/changes
for v2 going to take place on this winsock-hackers list, or on another list
I don't yet know about?


--
Paul Brooks              |[e-mail]       |Emerging Standard:
TurboSoft Pty Ltd        |[e-mail]|  one that has not yet
579 Harris St., Ultimo   |                         |  been superseded.
Sydney Australia 2007    |ph: [phone]       |
????
????
From halon.sybase.com!sybase.com!william Tue Feb  8 12:13:46 1994
From: William Wong <[e-mail]>
Message-Id: <[e-mail]>
Subject: Windows Sockets 2 Contribution
To: [e-mail]
Date: Tue, 8 Feb 94 12:13:22 PST
X-Mailer: ELM [version 2.3 PL0]
content-length: 348
Status: OR

Winsock 2.0 should add support for BOTH RFC 793 and RFC 1122 styles of
Out-Of-Band data.

Most Unix TCP/IPs use RFC 793 Out-Of-Band data, e.g. Sun4, HP, RS6000, etc.
However, Solaris is getting popular and it is using RFC 1122 OOB.  Winsock
2.0 implementation should support both and make it user configurable to switch
between the two.

William

????
????
From relay1.uu.net!netmanage.com!tmima Wed Feb  9 16:40:34 1994
Message-Id: <[e-mail]>
Date: Wed,  9 Feb 94 17:44:42 PST
Reply-To: Tmima Koren <[e-mail]>
From: Tmima Koren <[e-mail]>
To: Martin Hall <[e-mail]>
Subject: Windows Sockets 2 Contribution
Status: OR


shared sockets

Set 'shared' attribute to a socket, maybe with setsockopt().
A shared socket can be passed and used by all tasks.



????
????
From magnolia.banyan.com!banyan!eng!mike=procopio Thu Feb 10 10:58:05 1994
Date: Thu, 10 Feb 94 14:09:49 EST
From: Mike=[e-mail]
Subject: re:Windows Sockets 2 Contribution
To: [e-mail]
Cc:
Bcc:
Message-ID:  <[e-mail]>
Status: OR



I would like to see the spec address concurrent access of multiple address
families in a coherent (common across all implementations) way.

Currently, on DOS/Windows 3.1 it is necessary for an APP to use
LoadLibrary(),
and GetProcAddress() in order to concurrently access winsock.dll's from
multiple providers providing support for different address families.  There
should be a standard mechanism.

[e-mail]

????
????
From magnolia.banyan.com!banyan!eng!mike=procopio Thu Feb 10 10:59:47 1994
Date: Thu, 10 Feb 94 14:12:19 EST
From: Mike=[e-mail]
Subject: re:Windows Sockets 2 Contribution
To: [e-mail]
Cc:
Bcc:
Message-ID:  <[e-mail]>
Status: OR


The semantics of alternate address families need to be defined.

Currently, the winsock semantic definition is restricted to TCP/IP.  It needs
to address other address families as well: IPX/SPX, ISO, etc..

[e-mail]


????
????
From magnolia.banyan.com!banyan!eng!mike=procopio Thu Feb 10 11:04:27 1994
Date: Thu, 10 Feb 94 14:16:08 EST
From: Mike=[e-mail]
Subject: re:Windows Sockets 2 Contribution
To: [e-mail]
Cc:
Bcc:
Message-ID:  <[e-mail]>
Status: OR


Winsock should be enlarged to provide the concept of "in-system" usage.

Currently, winsock defines an API restricted to windows applications.  There
is a real need for a standard in-system interface as well.  The analogy is
in-system is to winsock what TPI is to TLI.

procopio@banyan,.com



????
????
From relay1.uu.net!netmanage.com!tmima Thu Feb 10 11:52:02 1994
Message-Id: <[e-mail]>
Date: Wed,  9 Feb 94 17:44:42 PST
Reply-To: Tmima Koren <[e-mail]>
From: Tmima Koren <[e-mail]>
To: Martin Hall <[e-mail]>
Subject: Windows Sockets 2 Contribution
Status: OR


set/get/remove ARP table entry



????
????
From relay1.uu.net!netmanage.com!tmima Thu Feb 10 11:52:43 1994
Message-Id: <[e-mail]>
Date: Wed,  9 Feb 94 17:44:42 PST
Reply-To: Tmima Koren <[e-mail]>
From: Tmima Koren <[e-mail]>
To: Martin Hall <[e-mail]>
Subject: Windows Sockets 2 Contribution
Status: OR


gethostid()


????
????
From relay1.uu.net!netmanage.com!tmima Thu Feb 10 12:34:01 1994
Message-Id: <[e-mail]>
Date: Wed,  9 Feb 94 17:44:42 PST
Reply-To: Tmima Koren <[e-mail]>
From: Tmima Koren <[e-mail]>
To: Martin Hall <[e-mail]>
Subject: Windows Sockets 2 Contribution
Status: OR


raw ICMP/IP



????
????
From mail.netcom.com!next.distinct.com!vikas Mon Feb 14 11:24:39 1994
From: Vikas Garg <[e-mail]>
Message-Id: <[e-mail]>
Subject: Windows Socket 2.0 Contributions
To: Martin Hall <[e-mail]>
Date: Mon, 14 Feb 1994 11:29:03 -0800 (PST)
Cc: Oliver Spaeth <[e-mail]>
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 691
Status: OR

RAW SOCKETS

Some level of support for the raw sockets should be included in
the specs. Wether the access is to be at the ICMP level or the
IP level should also be clarified.

You must me sick of this request by now, so I will leave it at
this :-)

Vikas
--
==========================================================
Vikas Garg                     Phone : [phone]
Distinct Corp.                 Fax   : [phone]
12901 Saratoga Ave., Ste. 4    E-Mail: [e-mail]
Saratoga, CA 95070
U.S.A.
==========================================================
????
????
From mail.netcom.com!next.distinct.com!vikas Mon Feb 14 11:36:51 1994
From: Vikas Garg <[e-mail]>
Message-Id: <[e-mail]>
Subject: Windows Socket 2.0 Contributions
To: Martin Hall <[e-mail]>
Date: Mon, 14 Feb 1994 11:41:12 -0800 (PST)
Cc: Oliver Spaeth <[e-mail]>
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 976
Status: OR

WSAAsyncSelect()

At this point in time I am sick of all the FD_@#$% discussions, whatever
way they are supposed to be posted, PLEASE remove the ambiguities.
i)   Should FD_CLOSE be posted when the connection goes into the
     FIN_WAIT state or when it goes into the FIN_WAIT state AND there
     is no data to be read.
ii)  Should FD_CLOSE be posted once only or for every WSAAsyncSelect call?
iii) Should FD_WRITE be posted only on connect() or accept() or also when
     WSAAsyncSelect() is called AFTER a successful connect() or accept().

==========================================================
Vikas Garg                     Phone : [phone]
Distinct Corp.                 Fax   : [phone]
12901 Saratoga Ave., Ste. 4    E-Mail: [e-mail]
Saratoga, CA 95070
U.S.A.
==========================================================
????
????
From netcom3.netcom.com!next.distinct.com!vikas Mon Feb 14 11:41:49 1994
From: Vikas Garg <[e-mail]>
Message-Id: <[e-mail]>
Subject: Windows Socket 2.0 Contributions
To: Martin Hall <[e-mail]>
Date: Mon, 14 Feb 1994 11:45:09 -0800 (PST)
Cc: Oliver Spaeth <[e-mail]>
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 541
Status: OR

Sharing of Sockets among applications

The topic says it all, you must be sick of this request also.

Vikas
--
==========================================================
Vikas Garg                     Phone : [phone]
Distinct Corp.                 Fax   : [phone]
12901 Saratoga Ave., Ste. 4    E-Mail: [e-mail]
Saratoga, CA 95070
U.S.A.
==========================================================
????
????
From mail.netcom.com!next.distinct.com!vikas Mon Feb 14 11:44:52 1994
From: Vikas Garg <[e-mail]>
Message-Id: <[e-mail]>
Subject: Windows Socket 2.0 Contributions
To: Martin Hall <[e-mail]>
Date: Mon, 14 Feb 1994 11:49:09 -0800 (PST)
Cc: Oliver Spaeth <[e-mail]>
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 919
Status: OR

Multiple Versions

Now that the situation to have multiple versions actually
exists, can a winsock dll support multiple versions??
I would recommend against it since it can cause a lot of
headaches if an application is using 2.0 and an intermediate
DLL is using 1.1.
If multiple version support is to be allowed, then please
clarify how this problem is to be resolved also the version
requested should not be ignored in subsequent calls to
WSAStartup (page 108 second para.)

Vikas
--
==========================================================
Vikas Garg                     Phone : [phone]
Distinct Corp.                 Fax   : [phone]
12901 Saratoga Ave., Ste. 4    E-Mail: [e-mail]
Saratoga, CA 95070
U.S.A.
==========================================================
????
????
From netcom3.netcom.com!next.distinct.com!vikas Mon Feb 14 11:48:01 1994
From: Vikas Garg <[e-mail]>
Message-Id: <[e-mail]>
Subject: Windows Sockets 2.0 Contributions
To: Martin Hall <[e-mail]>
Date: Mon, 14 Feb 1994 11:51:16 -0800 (PST)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 666
Status: OR

Hosts List

Some standard way for the applications to retrieve the list
of available hosts. Maybe a function that returns the hosts
as a linked list, or a standard way of saving the hosts in
a file in the windows directory.

Vikas

--
==========================================================
Vikas Garg                     Phone : [phone]
Distinct Corp.                 Fax   : [phone]
12901 Saratoga Ave., Ste. 4    E-Mail: [e-mail]
Saratoga, CA 95070
U.S.A.
==========================================================
????
????
From netcom3.netcom.com!next.distinct.com!vikas Tue Feb 15 21:30:11 1994
From: Vikas Garg <[e-mail]>
Message-Id: <[e-mail]>
Subject: Windows Socket 2.0 Contribution
To: Martin Hall <[e-mail]>
Date: Tue, 15 Feb 1994 17:15:17 -0800 (PST)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 799
Status: ORP
History: Replied to on 18 Feb 94

Yielding by an application

Can an application sit in a tight loop waiting on a select()
without yielding control at all? The current specs say that
this is illegal, however lot of applications (including WSAT)
use this programming model. I hope we can either clarify it
a bit more in the next version, or remove the requirement for
applications to yield...

Vikas
--
==========================================================
Vikas Garg                     Phone : [phone]
Distinct Corp.                 Fax   : [phone]
12901 Saratoga Ave., Ste. 4    E-Mail: [e-mail]
Saratoga, CA 95070
U.S.A.
==========================================================
????
????
From ormail.intel.com!intelhf.intel.com!ccm!david_b_andersen Wed Feb 16
13:28:25 1994
Date: Wed, 16 Feb 94 13:34:32 PST
From: David B Andersen <[e-mail]>
Message-ID: <[e-mail]>
To: [e-mail]
cc: [e-mail], [e-mail]
Subject: Input for Winsock ver 2
Status: OR


Text item: Text_1

                                                    02/16/94
Dear Martin,

Intel is pleased to supply the following input to the Winsock 2
definition process. There are 10 proposals in all, with this submittal
corresponding to proposal number 1.

For each of our proposals we supply a desciption of the proposed
extension, our motivations for making the extension proposal, and the
detailed syntax for how the extension might be implemented.

We would also like to volunteer our services to assist in the process
of collating and summarizing the various submitals that are coming in
from Forum members.  Please let us know how we can best assist you in
this process.

Regards,

David B. Andersen
Intel Architecture Labs


Extension #1:
     Replace vendor-specific Winsock.DLLs with a single DLL

Description:
Existing Winsock implementations are all vendor-specific
since no standard interface is defined for the interface
between Winsock.DLL and protocol stacks.  Version 2 of
Winsock should change the model by defining such an
interface (subsequently referred to as a Service Provider
Interface or SPI).

Motivation:
Some level of ambiguity remains in the current version of
the Winsock spec which results in subtle but sometimes
crucial differences in how various Winsock implementations
behave.  Having a single Winsock DLL would ensure more
uniform behavior, while allowing stack vendors to avoid
duplication of effort.  (Let's free up  their resources so
they can concentrate on improved versions of their stacks!)

This also paves the way for multiprotocol support as
outlined in our proposed extension #2.

Semantics:
A Winsock SPI specification would need to be created.   An
ini file will also need to be defined for the Winsock DLL
which would provide it with the information requried to
discover what underlying stacks were present and enable them
to be loaded as required.  Intel is prepared to make
additional suggestions for a  SPI specification and ini file
format if the forum wishes to pursue this proposal further.

????
????
From ormail.intel.com!intelhf.intel.com!ccm!david_b_andersen Wed Feb 16
13:31:23 1994
Date: Wed, 16 Feb 94 13:37:09 PST
From: David B Andersen <[e-mail]>
Message-ID: <[e-mail]>
To: [e-mail]
cc: [e-mail], [e-mail]
Subject: Input for Winsock ver 2
Status: OR


Text item: Text_1

                                                    02/16/94
Dear Martin,

Intel is pleased to supply the following input to the Winsock 2
definition process. There are 10 proposals in all, with this submittal
corresponding to proposal number 2.

For each of our proposals we supply a desciption of the proposed
extension, our motivations for making the extension proposal, and the
detailed syntax for how the extension might be implemented.

We would also like to volunteer our services to assist in the process
of collating and summarizing the various submitals that are coming in
from Forum members.  Please let us know how we can best assist you in
this process.

Regards,

David B. Andersen
Intel Architecture Labs


Extension #2:
     Support multiple transport protocols simultaneously

Description:
The Winsock interface should be generalized so as to provide
access to any transport layer protocol.  Furthermore, this
should be done in such a way that at single app may have
simultaneous access to multiple protocol stacks.  While a
unified addressing scheme that works across all protocols
would also be desirable, so too would solving world hunger.
For pragmatic reasons we suggest that Winsock version 2 not
try and include a universal addressing model.  Rather, it
should be entirely neutral with respect to the addressing
format of each underlying transport protocol.

Motivation:
While TCP/IP is an essential protocol stack, in the PC space
there are many others that are very important as well (e.g.
IPX, NetBIOS, DECNET, Vines, etc.).  Application developers
should not be required to utilize multiple APIs in order to
host their application on multiple transports.  Similarly,
it is very possible that the server side of a client/server
application may need to support various clients that do not
all utilize the same transport protocol.

Semantics:
This proposal also requires that a SPI and ini file format
be defined for Winsock as mentioned in our proposed
extension #1.  Intel is prepared to make additional
suggestions for a  SPI specification and ini file format if
the forum wishes to pursue this proposal further.

Implementation of this suggestion would also require that
the API verbage be carefully edited to remove the existing
bias towards and assumption of TCP/IP.  A few new functions
are needed  to allow an application to evaluate the
available transport choices and determine which transport to
use when creating new sockets or using the getXbyY database
routines.

We propose the creation of a new WSA function for
enumerating through the various service providers.  Syntax
is as follows:


   int PASCAL FAR WSAEnumProviders ( FARPROC lpfnCallback, int
iAddressFamily);

          lpfnCallback   Specifies the procedure instance
                    address of the callback function to be
                    invoked by Winsock.DLL for each Service
                    Provider.

          iAddressFamily Specifies the address family that
                    any enumerated Service Provider should
                    support.  This can be used as a filter,
                    so that an application can get a list of
                    Service Providers that support, e.g.,
                    AF_INET addresses.  To get a list of
                    every Service Provider, this parameter
                    should be zero.

          This function is used to enumerate the Service
          Providers registered with and therefore accessible
          from the Winsock.DLL.  It allows a descriptive
          text string, Service Provider Key, address family,
          socket types, and length of the address (in bytes)
          for each registered Service Provider to be
          retrieved.

          WSAEnumProviders() uses the standard Windows
          enumeration procedure using a "callback" function.
          The callback function is called once for each
          Service Provider registered in the "Winsock.ini"
          that matches the address family.  This will be
          repeated until either the callback function
          returns zero or the end of the list of Service
          Providers is reached.

          The prototype of the callback function is as
          follows:

      int PASCAL FAR CallbackFunc( LPSTR lpszDescription, char FAR *
          ProviderKey, int iAddressFamily, int FAR * lpSocketType,
                  int iAddressLength );

          CallbackFunc is a placeholder for the application-
          supplied function name.  The actual callback
          function must reside in a DLL or application
          module and be exported in the module definition
          file.  You must use MakeProcInstance() to get a
          procedure-instance address for the callback
          function.  The callback function must return
          nonzero to continue enumeration; to stop
          enumeration, it must return zero.

          lpSocketType points to a 0-terminated integer
          array indicating all the socket types supported by
          the Service Provider identified by ProviderKey
          along with a text description lpszDescription.
          The address family supported by the Service
          Provider is specified by iAddressFamily, and the
          (maximum) length of the address (in bytes) by
          iAddressSize, which allows applications to
          allocate a big enough buffer for address in this
          address family.

In addition, we propose a new WSA function to allow an
application to specify a particular service provider to use
when creating new sockets and when accessing the getXbyY
database routines.  Syntax for this function is as follows:

     int PASCAL FAR WSAProviderSelection ( char FAR * ProviderKey );

          ProviderKey    The Key of the Service Provider to
                              be selected.

Remarks   This function selects the Service Provider to be
          used for the current task until the next
          invocation of this function.  Winsock functions
          which may be affected by this function include
          socket(), getXbyY(), and WSAAsyncGetXByY().
          Applications can eliminate any pre-selected
          Service Provider by setting ProviderKey to be
          NULL.  This indicates to the Winsock DLL that it
          should determine for itself which service provider
          to use based on the socket type and address family
          parameters to the socket() call.  Whenever this
          function is used to set the provider selection to
          NULL, the default database provider as specified
          in the Winsock ini file is used for getXbyY
          functions.  The provider keys of Service Providers
          can be obtained by using WSAEnumProviders().

Finally, it is necessary to ignore the value of the
iMaxUdpDg field in the WSAData structure which is obtained
via the WSAStartup() function.  As a replacement for this,
we propose a new get-only socket option: SO_MAX_DG_SIZE.

????
????
From ormail.intel.com!intelhf.intel.com!ccm!david_b_andersen Wed Feb 16
13:36:00 1994
Date: Wed, 16 Feb 94 13:42:10 PST
From: David B Andersen <[e-mail]>
Message-ID: <[e-mail]>
To: [e-mail]
cc: [e-mail], [e-mail]
Subject: Input for Winsock ver 2
Status: OR


Text item: Text_1

                                                    02/16/94
Dear Martin,

Intel is pleased to supply the following input to the Winsock 2
definition process. There are 10 proposals in all, with this submittal
corresponding to proposal number 3.

For each of our proposals we supply a desciption of the proposed
extension, our motivations for making the extension proposal, and the
detailed syntax for how the extension might be implemented.

We would also like to volunteer our services to assist in the process
of collating and summarizing the various submitals that are coming in
from Forum members.  Please let us know how we can best assist you in
this process.

Regards,

David B. Andersen
Intel Architecture Labs


Extension #3:
     Expand the list of socket types and adopt a more
        desriptive naming convention

Description:
If Winsock provides access to  protocols other than TCP/IP
it will need to support more than just the SOCK_DGRAM and
SOCK_STREAM socket types.  We  propose an expanded set of
socket types that utilize a more descriptive and uniform
naming convention.  We do not advocate that service
providers be required to support all or any particular set
of socket types, with the exception that support for raw
sockets (SOCK_RAW) should be mandatory.  Some of the
communications properties which should be supported are:
connectedness, reliability, preservation of transmission
boundaries, directionality and isochronicity.

Motivation:
Sockets are typed according to the communication properties
visible to a user.  Socket type names should be chosen to
reflect the essential attributes of the corresponding
socket.  Other transport protocols support communications
properties different from those available within TCP/IP.  In
particular, protocol stacks that are optimized for real-time
multimedia applications have unique properties which must be
accessible to an application.

Proposed Semantics:
We propose that socket type naming be based on the following
convention:

     SOCK_RAW or
     SOCK_ [ REL | UNREL ][ _ISOCH ][ _UNISEND | _UNIRECV ]
           [_STREAM | _DGRAM |  _DSTREAM ]


Raw sockets provide a mechanism to bypass the usual protocol
layers and are very much dependent on the particulars of
each service provider.  Service providers should be required
to support raw sockets.

[ REL | UNREL ] indicates whether or not the socket provides
reliable communication.  Reliability  implies that the
transport will ensure that all transmitted information
arrives at the remote end or, failing in its attempts to
accomplish this,  will inform the application that reliable
communication with the designated endpoint is currently not
possible.

[ _ISOCH ] indicates that the socket supports isochronous
communications in which the time intervals between
successive transmissions are (apparently) maintained
throughout the network and reflected at the receiving end.

[ _UNISEND | _UNIRECV ] restricts a socket to be uni-
directional and allows only send or receive operations as
indicated.   Otherwise, all sockets are bi-directional.

[ _STREAM | _DSTREAM | _DGRAM ] indicates whether the socket
is connection-oriented (STREAM and DSTREAM) or
connectionless (DGRAM).  Connection-oriented, stream style
sockets guarantee that information arriving at the receiving
application will appear in correct sequence and without
duplication.  Note that this does not imply reliability
(guaranteeing that all of the information will arrive).
Rather it ensures that information which does arrive will be
unduplicated and in correct sequence.   Connectionless
sockets (DGRAM), do not possess stream attributes and hence
may provide information which is duplicated and/or out of
sequence.  The difference between a STREAM and a DSTREAM
socket is that message boundaries are not preserved in the
former(i.e. a byte stream) and are preserved in the latter
(i.e. a message stream).

Using this naming convention for socket types, the two
styles of communication supported by TCP/IP (TCP streams and
UDP datagrams) would be referred to as SOCK_REL_STREAM and
SOCK_UNREL_DGRAM respectively.  To maintain compatibility
with existing socket-based applications, the Winsock header
file would include alias definitions for the familiar
SOCK_STREAM and SOCK_DGRAM socket types.

????
????
From ormail.intel.com!intelhf.intel.com!ccm!david_b_andersen Wed Feb 16
13:38:06 1994
Date: Wed, 16 Feb 94 13:43:26 PST
From: David B Andersen <[e-mail]>
Message-ID: <[e-mail]>
To: [e-mail]
cc: [e-mail], [e-mail]
Subject: Input for Winsock ver 2
Status: OR


Text item: Text_1

                                                    02/16/94
Dear Martin,

Intel is pleased to supply the following input to the Winsock 2
definition process. There are 10 proposals in all, with this submittal
corresponding to proposal number 4.

For each of our proposals we supply a desciption of the proposed
extension, our motivations for making the extension proposal, and the
detailed syntax for how the extension might be implemented.

We would also like to volunteer our services to assist in the process
of collating and summarizing the various submitals that are coming in
from Forum members.  Please let us know how we can best assist you in
this process.

Regards,

David B. Andersen
Intel Architecture Labs


Extension #4:
     Provide a means for sockets to be shared across applications

Description:
We believe it is essential that a paradigm for socket
sharing be available in Winsock that is applicable to Win
3.1 as well as the Chicago and NT environments.  We are
uncomfortable with the approach of simply declaring that
socket values must be globally unique while removing any
existing checks that force the using and owning tasks to be
the same.  In environments such as Chicago and NT a socket
can be used as a file descriptor and we must assume,
therefore, that like file descriptors, socket values will
only have meaning within the context of the owning task.

Motivation:
Shared sockets have been frequently referred to on the net
as a desirable feature for version 2.  In our own work with
multimedia communications we have run across numerous
instances where this capability would lead to simplified
implementation.

Semantics:
We propose a new construct, which we refer to as a "virtual
socket", as a mechanism to avoid these difficulties.
Virtual socket are created in the context of the source task
by supplying an existing, local socket descriptor and a
handle to the target task (which could be the same task as
the source task) for which the virtual socket will be used:


     SOCKET  vs ;

     vs =  WSADuplicateSocket( SOCKET s, HTASK hTargetTask );


To get the target task's handle, it will generally  be
necessary to use some form of interprocess communication
(IPC), e.g., DDE and PostAppMessgage () in Windows 3.1, or
named pipe and shared memory in Windows NT.  Since vs is
only valid in the context of the target task, the source
task must pass the value of the virtual socket to the target
task, also via your favorite IPC mechanism.

Virtual sockets may be used in all places where regular
sockets are used and are, in fact, indistinguishable from
them.  Virtual sockets derived from a common underlying
socket share all aspects of the underlying shared socket
with the exception of the notification mechanism.  Reference
counting is employed to ensure that the underlying shared
socket is not closed until the last virtual socket is
closed.

Since the collection of attributes which comprise a virtual
socket's option set is shared, setting any socket option may
have a global effect.  For example, if one task uses
ioctlsocket() on a virtual socket to set it into non-
blocking mode, this change is visible to all of the virtual
sockets that reference the underlying shared socket.

 Each virtual socket has an independent notification
mechanism which conforms to the usual Winsock conventions.
For example, two tasks may wish to share a socket and
operate in a cooperative fashion where one is the sender and
the other the receiver.  Each task may arrange for
notification appropriate to its role.  In the pathological
case of two or more tasks sharing an underlying socket and
each requesting asynchronous notification  when data is
ready to be read (foolish thing to do that this may be), all
such tasks will receive their stipulated message in an
unspecified sequence.  The first task to perform a read will
get some or all of the available data, the others will get
what's left, if any.  In other words, in all cases it is
completely up to tasks which share a socket to coordinate
their access to the socket.

As an interesting aside, we note that simply invoking the
WSADuplicateSocket() function on a socket s, causes s itself
to become a virtual socket which references the original
(and now underlying) socket.


????
????
From intelhf.intel.com!ccm!david_b_andersen Thu Feb 17 15:42:39 1994
Date: Thu, 17 Feb 94 15:49:16 PST
From: David B Andersen <[e-mail]>
Message-ID: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: Input for Winsock ver 2
Status: OR


Text item: Text_1

                                                    02/17/94
Dear Martin,

Intel is pleased to supply the following input to the Winsock 2
definition process. There are 10 proposals in all, with this submittal
corresponding to proposal number 5.

For each of our proposals we supply a desciption of the proposed
extension, our motivations for making the extension proposal, and the
detailed syntax for how the extension might be implemented.

We would also like to volunteer our services to assist in the process
of collating and summarizing the various submitals that are coming in
from Forum members.  Please let us know how we can best assist you in
this process.

Regards,

David B. Andersen
Intel Architecture Labs


Extension #5:
     Provide support for protocol stacks which allow send()
     and recv() operations within interrupt context.

Description:
Some transport stacks allow an application to minimize
latency and maximize throughput by invoking the send and
receive operations from within interrupt context. A means
should be provided to determine which transport stacks
support this capability.  Also the application must have a
means to indicate to the Winsock DLL that a particular send
or receive invocation is occurring within interrupt context.

Motivation:
Apps which send media streams over communications channels
are often very sensitive to latency variations.  By
supporting send and receive operations in interrupt context
the amount of variance in perceived latency can be
minimized.  Also, by supporting this capability at the API
level, we encourage more stack vendors to support this
feature.

Semantics:
We propose that a new get-only socket option be defined:
SO_INTERRUPT.  This option would be used by a service
provider to indicate whether or not it supported interrupt
context operations.  Also, we propose the definition of an
additional bit in the flags parameter used with send(),
sendto(), recv() and recvfrom().  This bit would be called
MSG_INTERRUPT and would be used by the app to indicate to
the Winsock DLL that the particular send or receive
operation was being performed in interrupt context.


????
????
From intelhf.intel.com!ccm!david_b_andersen Thu Feb 17 15:45:29 1994
Date: Thu, 17 Feb 94 15:52:07 PST
From: David B Andersen <[e-mail]>
Message-ID: <[e-mail]>
To: [e-mail]
cc: [e-mail], [e-mail]
Subject: Input for Winsock ver 2
Status: OR


Text item: Text_1

                                                    02/17/94
Dear Martin,

Intel is pleased to supply the following input to the Winsock 2
definition process. There are 10 proposals in all, with this submittal
corresponding to proposal number 6.

For each of our proposals we supply a desciption of the proposed
extension, our motivations for making the extension proposal, and the
detailed syntax for how the extension might be implemented.

We would also like to volunteer our services to assist in the process
of collating and summarizing the various submitals that are coming in
from Forum members.  Please let us know how we can best assist you in
this process.

Regards,

David B. Andersen
Intel Architecture Labs


Extension #6:
     Provide callback notification

Description:
Applications should be able to select a callback style of
notification in addition to the current Windows message
based notification mechanism.  This would be the only
notification mechanism available for apps that perform send
and receive operation from within interrupt context.

The callback notification method should also allow an
application to supply an uninterpreted token as a parameter
to the notification request function, which is subsequently
returned to the app as a parameter of the callback function.

Motivation:
This is being proposed primarily as a means to support
interrupt context send and receive operations.  However,
significant additional value is added by including the user
supplied token.

Semantics:
We propose the a new WSA function be defined for requesting
callback notification:

int PASCAL FAR WSACallbackSelect ( SOCKET s, FARPROC lpfnCallback,
          DWORD dwCallbackData,  long lEvent );


          s          A descriptor identifying the socket for
                    which event notification is required.

          lpfnCallback   The procedure instance address of
                    the callback function to be invoked by
                    Winsock.DLL whenever a registered
                    network event happens.

          dwCallbackData A callback data passed back to the
                    application in the callback.  This
                    object is not interpreted by Winsock
                    implementation.

          lEvent    A bit mask which specifies a combination
                    of network events in which the
                    application is interested.


          This function will enable the function-based
          callback mechanism for the specified socket.
          WSACallbackSelect() is designed to get around the
          potential Windows message delay introduced by the
          WSAAsyncSelect() mechanism in order to support
          delay-sensitive applications.  The callback
          function will be invoked whenever Winsock detects
          any of the network events specified by the lEvent
          parameter.  The socket for which notification is
          required is identified by s.   The dwCallbackData
          will be passed back to the application along with
          the callback.

          This function automatically sets socket s to non-
          blocking mode.

          The prototype of the callback function is as
          follows:

               VOID PASCAL FAR CallbackFunc( SOCKET s, long
          lEvent, int    ErrorCode, DWORD dwCallbackData );



????
????
From intelhf.intel.com!ccm!david_b_andersen Thu Feb 17 15:45:52 1994
Date: Thu, 17 Feb 94 15:52:09 PST
From: David B Andersen <[e-mail]>
Message-ID: <[e-mail]>
To: [e-mail]
cc: [e-mail], [e-mail]
Subject: Input for Winsock ver 2
Status: OR


Text item: Text_1

                                                    02/17/94
Dear Martin,

Intel is pleased to supply the following input to the Winsock 2
definition process. There are 10 proposals in all, with this submittal
corresponding to proposal number 7.

For each of our proposals we supply a desciption of the proposed
extension, our motivations for making the extension proposal, and the
detailed syntax for how the extension might be implemented.

We would also like to volunteer our services to assist in the process
of collating and summarizing the various submitals that are coming in
from Forum members.  Please let us know how we can best assist you in
this process.

Regards,

David B. Andersen
Intel Architecture Labs


Extension #7:
     Socket groups

Description:
We propose that the notion of a socket group be introduced
as a means for an application (or cooperating set of
applications) to indicate to an underlying service provider
that a particular set of sockets are related and that the
group thus formed has certain attributes.  Proposed group
attributes include relative priorities of the individual
sockets within the group and a group quality of service
specification.  A new function is also proposed to allow an
application to enumerate through the member sockets of a
group.

Motivation:
Applications needing to exchange multiple media streams over
the network are benefited by being able to establish a
specific relationship among the set of sockets being
utilized.  As a minimum this might include a hint to the
service provider about the relative priorities of the media
streams being carried.  For example, a conferencing
application would want to have the socket used for carrying
the audio stream be given higher priority than that of the
socket used for the video stream.

Furthermore, there are transport providers (e.g. digital
telephony and ATM) which can utilize a group quality of
service specification to determine the appropriate
characteristics for the underlying call.  The sockets within
this group would then be multiplexed in the usual manner
over this call.  By allowing the application to identify the
sockets that make up a group and to specify the required
group attributes, such service providers can operate with
maximum effectiveness.

Semantics:
We propose that the grouping of sockets be performed at the
time when a connection request is made or when incoming
socket connections are accepted.  This would include both
the creation of new groups and the addition of a socket to
an existing group.  Also, we suggest that two different
types of groups be supported: constrained and unconstrained.
In all cases sockets to be grouped must be associated with
the same service provider.  Sockets joined into an
unconstrained group may have any host as their destination.
Sockets joined to a constrained group must all have the same
host as their destination (although the port number portion
of their destination addresses may certainly differ).  The
syntax for a WSA version of connect would be as follows:

int PASCAL FAR WSAConnectEx ( SOCKET s, const struct sockaddr FAR * name,
          int namelen, GROUP g, char  FAR * lpSFlowspec, int iSFlowspecLen,
          char FAR * lpGFlowspec, int iGFlowspecLen );

          s          A descriptor identifying an unconnected
                    socket.

          name      The name of the peer to which the socket
                    is to be connected.

          namelen   The length of the name.

          g         The identifier of the socket group.

          lpSFlowspec    A pointer to the flow spec for
                    socket s.

          iSFlowspecLen  The length of the flow spec for
                    socket s.  It must be larger than or
                    equal to the size of struct FLOWSPEC.

          lpGFlowspec    A pointer to the flow spec for the
                    socket group to be created, if the value
                    of parameter g is SG_CONSTRAINED_GROUP.

          iGFlowspecLen  The length of the flow spec for the
                    socket group to be created, if the value
                    of parameter g is SG_CONSTRAINED_GROUP.
                    It must be larger than or equal to the
                    size of struct FLOWSPEC.

          This function is used to create a connection to
          the specified destination.  For connection-
          oriented sockets (e.g., type SOCK_STREAM), an
          active connection is initiated to the foreign host
          using name (an address in the name space of the
          socket;).  When the socket call completes
          successfully, the socket is ready to send/receive
          data.

          For a connectionless socket (e.g., type
          SOCK_UNREL_DGRAM), the operation performed by
          WSAConnectEx() is merely to establish a default
          destination address which will be used on
          subsequent send() and recv() calls.

          If the socket, s, is unbound, unique values are
          assigned to the local association by the system,
          and the socket is marked as bound.  Note that if
          the address field of the name structure is all
          zeroes, WSAConnectEx() will return the error
          WSAEADDRNOTAVAIL.

          Parameter g is used to indicate the appropriate
          actions on socket groups:
           if g is an existing socket group id, add s to
                         this group, provided all the requirements
                         set by this group are met; or

           if g = SG_UNCONSTRAINED_GROUP, create an
                          unconstrained socket group and have
                          s as the first member; or

           if g = SG_CONSTRAINED_GROUP, create a
                          constrained socket group and have s as
                          the first member; or

           if g = NULL, no group operation is performed.

          For an unconstrained group, any set of sockets may
          be grouped together as long as they are supported
          by a single Service Provider and are connection-
          oriented.  A constrained socket group requires
          that connections on all grouped sockets be to the
          same host.  For newly created socket groups, the
          new group id can be retrieved by using
          getsockopt() with option SO_GROUP_ID, if this
          connect operation completes successfully.

          lpSFlowspec, and iSFlowspecLen specify a block of
          memory containing the flow spec for socket s, if s
          is unidirectional and a DSTREAM type socket.
          Otherwise, these values are ignored.  The first
          part of this memory block is struct FLOWSPEC,
          followed by any Service Provider specific data.
          Thus, iSFlowspecLen must be larger than or equal
          to the size of struct FLOWSPEC.  A NULL value for
          lpSFlowspec indicates no application supplied flow
          spec.

          lpGFlowspec, and iGFlowspecLen specify a block of
          memory containing the flow spec for the socket
          group to be created, if (and only if) the value of
          parameter g is SG_CONSTRAINED_GROUP.  Otherwise,
          these values are ignored.  The first part of this
          memory block is struct FLOWSPEC, followed by any
          Service Provider specific data.  Thus,
          iGFlowspecLen must be larger than or equal to the
          size of struct FLOWSPEC.  A NULL value for
          lpGFlowspec indicates no application supplied flow
          spec.

Similarly, a WSA version of accept is also proposed.  The
alert reader will note that the proposed function
incorporates conditional acceptance as well as grouping.
Conditional acceptance is discussed in greater detail in our
proposed extension #9.  The syntax is as follows:

SOCKET PASCAL FAR WSAAcceptEx ( SOCKET s, struct sockaddr
          FAR * addr, int FAR * addrlen, FARPROC lpfnCondition );

          s          A descriptor identifying a socket which
                    is listening for connections after a
                    listen().

          addr      An optional pointer to a buffer which
                    receives the address of the connecting
                    entity, as known to the communications
                    layer.  The exact format of the addr
                    argument is determined by the address
                    family established when the socket was
                    created.

          addrlen   An optional pointer to an integer which
                    contains the length of the address addr.

          lpfnCondition  The procedure instance address of
                    the application-supplied condition
                    function which will make an
                    accept/reject decision based on the
                    caller information passed in as
                    parameters, and optionally create and/or
                    join a socket group by assigning
                    appropriate value to the result
                    parameter g of this function.

          This routine extracts the first connection on the
          queue of pending connections on s, and checks it
          against the condition function.  If the condition
          function returns TRUE, this routine creates a new
          socket with the same properties as s and returns a
          handle to the new socket, and then optionally
          creates and/or joins a socket group based on the
          value of the result parameter g.  Otherwise,
          reject this connection request, and proceed to the
          next one.  If no pending connections are present
          on the queue, and the socket is not marked as non-
          blocking, WSAAcceptEx() blocks the caller until a
          connection is present.  If the socket is marked
          non-blocking and no pending connections are
          present on the queue, WSAAcceptEx() returns an
          error as described below.  The accepted socket may
          not be used to accept more connections.  The
          original socket remains open.

          The prototype of the condition function is as
          follows:

       BOOL PASCAL FAR ConditionFunc( const char FAR
          * caller, int callerlen, GROUP FAR * g);

          ConditionFunc is a place holder for the
          application-supplied function name.  The actual
          condition function must reside in a DLL or
          application module and be exported in the module
          definition file.  You must use MakeProcInstance()
          to get a procedure-instance address for the
          callback function.  The exact format of the caller
          parameter is determined by the address family in
          which the communication is occurring.

          The result parameter g is assigned within the
          condition function to indicate the following
          actions:
               if g is an existing socket group id, add s to
          this group, provided all the requirements
           set by this group are met; or

          if g = SG_UNCONSTRAINED_GROUP, create an
                         unconstrained socket group and have
                         s as the first member; or

          if g = SG_CONSTRAINED_GROUP, create a constrained
                          socket group and have s as the first member; or

          if g = NULL, no group operation is performed.

          For unconstrained groups, any set of sockets may
          be grouped together as long as they are supported
          by a single Winsock Service Provider and are
          connection-oriented.  A constrained socket group
          requires that connections on all grouped sockets
          be to the same host.  For newly created socket
          groups, the new group id can be retrieved by using
          getsockopt() with option SO_GROUP_ID, if this
          connection operation completes successfully.

          The argument addr is a result parameter that is
          filled in with the address of the connecting
          entity, as known to the communications layer.  The
          exact format of the addr parameter is determined
          by the address family in which the communication
          is occurring.  The addrlen is a value-result
          parameter; it should initially contain the amount
          of space pointed to by addr; on return it will
          contain the actual length (in bytes) of the
          address returned.  This call is used with
          connection-oriented socket types such as
          SOCK_STREAM.  If addr and/or addrlen are equal to
          NULL, then no information about the remote address
          of the accepted socket is returned.


In addition to the new connect function, we need a few new
socket options: SO_GROUP_ID and SO_GROUP_PRIORITY.  The
group ID option is a get-only value used to discover the ID
of any group that a particular socket belongs to.  It is
also the method used to discover the ID of a newly created
group.  The group priority option is used to establish (or
discover) the relative priority of a socket within its
group.  Zero represents the highest priority.

Finally, we need a way to discover which sockets belong to a
particular group.  To accomplish this we propose a new
function: WSAEnumGroup():  The syntax is as follows:

          int PASCAL FAR WSAEnumGroup ( GROUP g, FARPROC lpfnCallback );

          g         Specifies the identifier of the socket
                    group for which membership information
                    is retrieved.

          lpfnCallback   Specifies the procedure instance
                    address of the callback function to be
                    invoked by Winsock.DLL for each member
                    socket in the group.

Remarks   This function is used to enumerate the members in
          the specified socket group.  It uses the standard
          Windows enumeration procedure using a "callback"
          function.  The callback function is called once
          for each member in the specified socket group.
          This will be repeated until either the callback
          function returns zero or the end of the member
          list has been reached.  On each invocation of the
          callback function, a "virtual socket" descriptor
          will be passed in as a parameter.  (For a detailed
          description of virtual sockets, please see
          WSADuplicateSocket().)  The value of the virtual
          socket parameter must either be copied to another,
          non-transient SOCKET variable and retained across
          invocations of the callback function, or the
          virtual socket must be closed prior to returning.
          Failure to do so will result in a resource leak
          through lost references to virtual sockets.

          The prototype of the callback function is as
          follows:

               int PASCAL FAR CallbackFunc( SOCKET s );

          CallbackFunc is a place holder for the application-
          supplied function name.  The actual callback
          function must reside in a DLL or application
          module and be exported in the module definition
          file.  You must use MakeProcInstance() to get a
          procedure-instance address for the callback
          function.  The callback function must return non
          zero to continue enumeration; to stop enumeration,
          it must return zero.


????
????
From cayman.cayman.com!wayne Thu Feb 17 19:24:01 1994
Message-Id: <[e-mail]>
X-Sender: wayne@cuba
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 17 Feb 1994 22:25:33 -0500
To: [e-mail]
From: "Wayne F. Tackabury" <[e-mail]>
Subject: Windows Sockets v.2 Extensions
X-Mailer: <PC Eudora Version 1.4b18>
Status: OR

The calendar on the wall is reminding me that tomorrow is the cutoff date
for Winsock v.2 extensions (I also lost the piece of mail which first
informed me of this...I recall you're the man to send them to).  I have two
in mind, but haven't had time to really develop them...perhaps if you can
give me any validation as to their reasonableness (from your objective lofty
vantage point :-)) or redundancy relative to already suggested, or shot
down, proposed extensions.

ONE would be a hosts enumeration function.  I am trying to solve two
problems here; one, for conventional INET family-targeted applications, is
to simply allow a bulk transfer of the hosts information, independent of the
underlying static or network services used to retrieve them.  The other is
to facilitate Winsock support for protocols which depend heavily on browsing
of hierarchical names to retrieve inherently dynamic bound addresses
(AppleTalk comes to mind).

The trick (which I've not yet completely solved beyond the following) is to
have an argument to WSAAsyncGetHostList() which would describe the hierarchy
context for lookup.  In the case of INET, this is an array of strings
constraining a DNS zone, NIS domain, or whathaveyou; in the case of
AppleTalk it represents a three level array string which would constrain or
wildcard the AppleTalk NBP name, type, and zone.  Hence

WSAAsyncGetHostList( HWND hWnd,  // Window handle for notification
                   unsigned int wMsg, // message for notification
                   const char far **nameContext, /* Array of string pointers
                                                   describing hierarchical
                                                   context for lookup, address
                                                   family-specific */
                   char far *buf,       // buffer for return info
                   int  buflen)         // Buffer length, in hostent structs


Return of WSAENOBUFS would return actually received number of matching
hostents in lparam, allowing the application to adjust amount of buffering
allocated for return.  After a bunch of time with protocol-general ways of
envisioning FindFirst/FindNext-style "next entry index", or dealing with the
arduous AppleTalk-style "here's my list of hosts I've already heard from,
only give me ones not in this list" interface semantics, I have come to the
conclusion that the best, albeit less performance-friendly, way of dealing
with this is to let the application worry about it.

I'd be very very suprised if this proposal hasn't been raised somewhere
before.

TWO, I've only started thinking about in the last day or two...it would
involve allowing a calling application to set the network protocol address
of an interface. One could either have a straight sethostaddr() function, or
tie it into a more general non-socket ioctl() function; to solve what I'm
trying to solve, you don't need the latter necessarily (to set subnet
address, max datagram size, etc. system wide; but then again, I'm not trying
to write a generalized DHCP client).

If you've used PPP, you can see the problem I'm getting at here; unless the
PPP client is part of a monolithic TCP kernel, there is no way to allow
server-assigned interface adddresses directly...so near as I can tell,
people are forcing the issue by using bootp and rarp where they aren't
really called for.  This would provide common semantics for configuration of
interfaces for service without providing their known addresses.

Anyways, I've waxed on long enough with content of dubious originality and
value...if you think there's value in pursuing this, let me know how you are
planning to bring these kinds of proposals to the list, and I'll hack more
complete prototypes together.

Thanks,

Wayne

----------------------------------

There is such a fine line between genius and stupidity.
                               -- Nigel Tufnel, *Spinal Tap*

Wayne F. Tackabury                       Cayman Systems, Inc.
400 Unicorn Park Dr., Woburn MA  01801   Internet: [e-mail]
Voice: [phone]                    Fax: [phone]
CompuServe: 73207,3650                   AppleLink: D0523

????
????
From relay1.uu.net!netmanage.com!tmima Fri Feb 18 11:51:11 1994
Message-Id: <[e-mail]>
Date: Fri, 18 Feb 94 12:54:20 PST
Reply-To: Tmima Koren <[e-mail]>
From: Tmima Koren <[e-mail]>
To: [e-mail]
Subject: Windows Sockets 2 Contribution
Status: OR


sethostent()
gethostent()
endhostent()

setprotoent()
getprotoent()
endprotoent()

setservent()
getservent()
endservent()

????
????
From ormail.intel.com!intelhf.intel.com!ccm!david_b_andersen Fri Feb 18
13:31:23 1994
Date: Fri, 18 Feb 94 13:38:01 PST
From: David B Andersen <[e-mail]>
Message-ID: <[e-mail]>
To: [e-mail]
cc: [e-mail], [e-mail]
Subject: Input for Winsock Ver 2
Status: OR


Text item: Text_1

                                                    02/18/94
Dear Martin,

Intel is pleased to supply the following input to the Winsock 2
definition process. There are 10 proposals in all, with this submittal
corresponding to proposal number 8.

-------> IMPORTANT NOTE: <-------------------
Because of limitiations in the somewhat brain-dead
mailer I am using, this submittal is being broken up into two pieces.
Please merge them back together when both pieces arrive.  This is part
1 of 2 pieces which comprise submittal #8.


Regards,

David B. Andersen
Intel Architecture Labs


Extension #8:
     Quality of service specification

Description:
As alluded to in our proposed extension # 7, applications
need a way to specify required quality of service levels
(QOS) for sockets and socket groups.  We feel strongly that
a mechanism for specifying QOS in Winsock QOS should be
compatible with corresponding work being done under the
auspices of the IETF.  RFC 1363 proposes a QOS specification
mechanism referred to as a flow spec. We have based our
proposal for how QOS should be specified at the API level on
the flow spec concept.

A brief overview of this concept is as follows:  Flow specs
describe a set of characteristics about a proposed
connection-oriented, unidirectional flow through the
network.  An application may associate a flow spec with a
socket at the time a connection request is made.  This flow
spec indicates parametrically what level of service is
required and also stipulates how flexible the application is
willing to be if the requested level of service is not
available.  (This ranges from "don't make a connection if I
don't get all that I asked for", to "here is what I would
like but I'll take anything I can get".)  After a connection
is established, the application may retrieve the flow spec
associated with the socket and examine its contents to
discover the level of service that the network is willing
and/or able to provide.  If the service provided is not
acceptable, the application may close the socket and take
whatever action is appropriate (e.g. scale back and ask for
a lower quality of service, try again later, notify the user
and exit, etc.)

Even after a flow is established, conditions in the network
may change resulting in a reduction (or increase) in the
available service level.  A notification mechanism is
included which utilizes the existing (and proposed) Winsock
notification techniques to indicate to the application that
QOS levels have changed.  The app should again retrieve the
corresponding flow spec and examine it in order to discover
what aspect of the service level has changed.

Semantics:
The basic QOS mechanism proposed for Winsock revolves around
the flow specification (or "flow spec") as described by
Craig Partridge in RFC 1361, dated September 1992.  Flow
specs provide a parametric representation of key QOS
characteristics.  Winsock's notion of a flow spec is a
backwards compatible extension of that defined in RFC 1363.
Applications use flow specs to indicate their service
requirements, and networks use flow specs to indicate QOS
availability.  Flow specs divide QOS characteristics into
the following general areas:

1.Network bandwidth utilization - The manner in which the
  application's traffic will be injected into the network.
  This includes specifications for average bandwidth
  utilization, maximum burst duration and peak burst rate.
  It also includes an indication which the network may
  provide of minimum link bandwidth (i.e. how wide the
  skinniest pipe is between the two hosts).

2.Sensitivity to delay - Applications indicate a delay or
  latency value as a target for the network, with an
  understanding that further reductions in delay below this
  value are of marginal use to the application.  A means is
  also provided to stipulate the maximum amount of delay
  variation that can be tolerated.

3.Willingness to cope with data loss and service
  interruption - Loss properties are expressed in terms of
  both overall percentage of lost packets and maximum
  amounts of bursty loss.  Service interruption indicates
  how long the application is willing to tolerate loss of
  all communication with the endpoint before considering
  the connection broken.

4.Level of service guarantee -  Applications are able to
  indicate a range of requirements, from the need for an
  ironclad guarantee to a willingness to accept whatever is
  available after merely expressing a hint about QOS
  preferences.

5.Flow content identification - Applications may select
  from a wide selection of well-known constants to identify
  the media content of a flow.

6.Cost sensitivity - An indication of how willing the
  application is to minimize communications cost to the
  possible detriment of other QOS parameters.

7.Communications security - Applications may specify a
  particular encryption system or option and identify
  public keys to be used

Flow specs are only applicable to DSTREAM style sockets
which are  unidirectional (either inbound or outbound).  An
application indicates its desire for a non-default flow spec
at the time a connection request is made.  Since
establishing a flow spec'd connection is likely to involve
cooperation and/or negotiation between intermediate routers
and hosts, the results of a flow spec request cannot be
determined until after the connection operation is fully
completed.  After this time, the application may use
getsockopt() to retrieve the resulting flow spec structure
so that it can determine what the network was willing and/or
able to supply.

Also, it is entirely possible that QOS conditions may change
during the life of a connection.  A means is provided,
therefore, for a service provider to notify the application
that it should access and inspect the current flow spec
which will have one or more modified values.

The Flow Spec Structure

The proposed flow spec structure is defined as follows.
Portions of the comment fields shown in italics indicate the
corresponding flow spec field identifier as found in RFC
1363.

          typedef struct FlowSpec {
          int   iMaxMsgSize;            // MTU: Max message size: bytes
          float fAvgBw;                 // Token Bucket Rate: bytes/sec
          float fBurstLength;           // Token Bucket Size: bytes
          float fBurstRate;         // Max Trans Rate: bytes/sec
          float fMinLinkSpeed           // Size of thinnest pipe: bytes/sec
                  int   iConnectionStatus       // Status of the connection
          int   iMinDelaySel;           // Minimum Delay Noticed:
          float fMinDelayValue;     // Delay value: usec
          float fMaxDelayVariation; // Max Delay Variation: usec
          int   iLossSensitivity;   // Loss Sensitivity:
          float fMaxLostPkts;           // Max # lost MTU's over...
          float fLossInterval;      // Loss Interval in MTU's
          float fMaxBurstLoss;      // Burst Loss Sensitivity
                                        // max # consec. lost MTU's
          int   iMaxSvcOutage;      // Max dur for svc outage: sec
          int   iQualOfGuarantee;   // Quality of Guarantee
          int   iFlowContent;           // flow content identifier
          int   iCostSensitivity;   // Cost sensitivity
          int   iEncryptionSel;     // Selected encryption algo
          char far *lpEncryptionKey; // Pointer to desired key
          } FLOWSPEC;


The sections which follow provide a detailed description of
each field in the flow spec.

iMaxMsgSize

This field corresponds to the Maximum Transmission Unit
field in RFC 1363.  It describes the maximum sized message
(in bytes) that the application intends to send over the
flow.  This must, of course, be no larger than the value of
SO_MAX_DG_SIZE for the underlying service provider.  The
intent of expressing this value in the flow spec is not to
provide a hard limit for the application.  Rather, it serves
two different purposes.

First, it is a convenient unit for expressing loss
properties.  Using the default MTU of the internetwork is
inappropriate since the internetwork may have a very large
MTU, such as the 64 Kbytes of IP, but applications and hosts
may be sensitive to losses of far less than an MTU's amount
of data. For example, a voice application would be sensitive
to a loss of several consecutive small packets.

Secondly, the MTU also bounds the amount of time that a flow
can transmit, uninterrupted, on a shared media.  Similarly,
the loss rates of links that suffer bit errors will vary
dramatically based on the MTU size.

fAvgBw

This field corresponds to the Token Bucket Rate field in RFC
1363.  It is one of three fields used to define how traffic
will be injected into the internetwork by the sending
application.

As flow specs are based upon the well-known leaky bucket
algorithm for flow control, this field and several others
are described in terms of imaginary tokens and buckets.  The
token rate is the rate at which tokens (credits) are placed
into an imaginary token bucket, expressed in bytes/second.
For each flow, a separate bucket is maintained.  To send a
packet over the flow, a host must remove a number of credits
equal to the size of the packet from the token bucket.  If
there are not enough credits, the host must wait until
enough credits accumulate in the bucket.

Note that the fact that the rate is expressed in terms of a
token bucket rate does not mean that hosts must implement
token buckets. Any traffic management scheme that yields
equivalent behavior is permitted.

The field indicates the number of byte credits (i.e., right
to send a byte) per second which are deposited into the
token bucket.  The value zero is slightly special.  It is used to
indicate that the application is not making a request for bandwidth
guarantees. If this field is zero, then the fBurstLength
field must also be zero, and the type of guarantee requested
may be no higher than predicted service (explained below).

fBurstLength

This field corresponds to the Token Bucket Size field in RFC
1363.  It controls the maximum amount of data that the flow
can send at the peak rate, and is expressed in terms of
bytes.  More formally, if the burst length is B, and the
average rate is R, over any arbitrarily chosen interval T in
the life of the flow, the amount of data that the flow sends
cannot have exceeded B + (R * T) bytes.

The imaginary token bucket is filled at the token bucket
rate.  The bucket size (or burst length) limits how many
credits the flow may store.  When the bucket is full, new
credits are discarded.

The field is ignored if the fAvgBw field is zero.  Note that
fBurstLength must be greater than or equal to iMaxMsgSize.
Zero is a legal value for the field and indicates that no
credits are saved.

fBurstRate

This field corresponds to the Maximum Transmission Rate
field in RFC 1363, and is expressed in bytes/second.  This
rate limits how fast packets may be sent back to back from
the host.  Consider that if the token bucket is full, it is
possible for the flow to send a series of back-to-back
packets, with the length of this run equal to the size of
the token bucket (fBurstLength).  If the token bucket size
is large, this back-to-back run may be long enough to
significantly inhibit multiplexing.  To limit this effect,
fBurstRate bounds how fast successive packets may be placed
on the network.

One can think of fBurstRate  as being a form of a leaky
bucket.  When a packet is sent, a number of credits equal to
the size of the packet is placed into an empty bucket, which
drains credits at the burst rate.  No more packets may be
sent until the bucket has emptied again.

fMinLinkSpeed

This field is an extension to the RFC 1363 flow spec, and is
expressed in bytes/second.  It is provided as a way for the
network to supply useful information to the application.

After a connection has been established, an application may
examine this field in order to determine the capacity
limitations of the underlying hops which the connection
spans.  All such hops will have a capacity greater than or
equal to fMinLinkSpeed.

A typical way for an application to use this field would be to
initiate a connection requesting the lowest possible level of service.
Once the connection is established, the app may then determine that higher
levels of service are likely possible.  It may then elect to either
modify its use of the socket or perhaps trade its current socket in on
one with a higher level of service.

A value of zero implies that this information is not
available from the network. This field is undefined for
unconnected sockets.

iConnectionStatus

This field is an extension to the RFC 1363 flow spec.  It is provided
as a way for the network to indicate a change in the connection status
to the application using one of the following manifest constants as
values: OPERATIONAL,  INTERRUPTED, or SUSPENDED.  Typical scenarios
might include: connection status on our cellular modem link changes
to INTERRUPTED because our car just drove into a tunnel, and then
changes back to OPERATIONAL when we come out the other side.  Later
on, connection status changes to SUSPENDED because we are going into
power conservation mode.  The availability of connection status may be
especially useful for situations where the iMaxSvcOutage value
is fairly long.

A value of UNKNOWN implies that this information is not available
from the network. This field is undefined for unconnected sockets.

----------  End of Part 1  ------ Continued in Part 2  ---------


????
????
From ormail.intel.com!intelhf.intel.com!ccm!david_b_andersen Fri Feb 18
13:32:28 1994
Date: Fri, 18 Feb 94 13:39:08 PST
From: David B Andersen <[e-mail]>
Message-ID: <[e-mail]>
To: [e-mail]
cc: [e-mail], [e-mail]
Subject: Input for Winsock Ver 2
Status: OR


Text item: Text_1

                                                    02/18/94
Dear Martin,

This is part 2 of 2 pieces which comprise our submittal #8.

Because of limitiations in the somewhat brain-dead
mailer I am using, this submittal is being broken up into two pieces.
Please merge them back together when both pieces arrive.


Regards,

David B. Andersen
Intel Architecture Labs

------------ Begin Part 2 of Submittal #8  -----------------------

iMinDelaySel and fMinDelayValue

These two fields both map to the Minimum Delay Noticed field
in RFC 1363.  Winsock uses two fields because in the RFC the
corresponding value may either be one of a set of manifest
constants or a floating point number.  The iMinDelaySel
field is used to represent the manifest constant, and, if
applicable, the fMinDelayValue field is used to store the
floating point value in microseconds.

The minimum delay noticed field tells the internetwork that
the host and application are effectively insensitive to
improvements in end-to-end delay below this value.  The
network is encouraged to drive the delay down to this value
but need not try to improve the delay further.

If expressed as a number it is the number of microseconds of
delay below which the host and application do not care about
improvements.  Human users only care about delays in the
millisecond range but some applications will be computer to
computer and computers now have clock times measured in a
handful of nanoseconds.  For such computers, microseconds
are an appreciable time.  For this reason, this field
measures in microseconds, even though that may seem small.

Manifest constants for iMinDelaySel are as follows:

  NO_DELAY_SENSITIVITY  -- the application is not sensitive
  to delay

  MODERATE_DELAY_SENSITIVITY -- the application is
  moderately delay sensitive (e.g., avoid satellite links
  where possible)

  NUMERIC_DELAY_SENSITIVITY -- the application is sensitive
  to delay as expressed in fMinDelayValue

fMaxDelayVariation

This field corresponds to the Maximum Delay Variation field
in RFC 1361. It is the difference, in microseconds, between
the maximum and minimum possible delay that a packet will
experience.  If a receiving application requires data to be
delivered in the same pattern that the data was transmitted,
it may be necessary for the receiving host to briefly buffer
data as it is received so that the receiver can restore the
old transmission pattern.  (An easy example of this is a
case where an application wishes to send and transmit data
such as voice samples, which are generated and played at
regular intervals.  The regular intervals may be distorted
by queuing effects in the network and the receiver may have
to restore the regular spacing.)

The amount of buffer space that the receiving host is
willing to provide determines the amount of variation in
delay permitted for individual packets within a given flow.
The maximum delay variation field makes it possible to tell
the network how much variation is permitted.

The value of 0, meaning the receiving host will not buffer
out delays, is acceptable but the receiving host must still
have enough buffer space to receive a maximum transmission
unit sized packet from the sending host.  Note that it is
expected that a value of 0 will make it unlikely that a flow
can be established.

iLossSensitivity, fMaxLostPkts and fLossInterval

These fields together correspond to the Loss Sensitivity and
Loss Interval fields in the RFC. iLossSensitivity takes on
one of the following well-known values:

  NO_LOSS_SENSITIVITY -- The application is not sensitive
  to loss, relying on higher level protocols if needed.

  SOME_LOSS_SENSITIVITY -- The application is sensitive to
  loss but is not specifying a numeric requirement.  Where
  possible, the network should choose a path with minimal
  loss.

  NUMERIC_LOSS_SENSITIVITY -- The application requires that
  loss characteristics be as described in fMaxLostPkts and
  fLossInterval.

fMaxLostPkts specifies the maximum number of MTU sized
packets that may be lost over an interval during which
fLossInterval MTU sized packets were sent.  Thus, taken
together, these values specify an average loss percentage.

fMaxBurstLoss

This field corresponds to the Burst Loss Sensitivity field
in the RFC. It states how sensitive the application's flow
is to losses of consecutive packets.  The field enumerates
the maximum number of consecutive MTU-sized packets that may
be lost.  A value of zero indicates that the flow is
insensitive to burst loss.

Note that it is permissible to set the iLossSensitivity
field to simply indicate some sensitivity to loss, and set a
numerical limit on the number of consecutive packets that
can be lost.

iMaxSvcOutage

This field represents an extension to the RFC flow spec.  It
indicates to the network a time interval, expressed in
seconds (not microseconds), during which communications over
the connection may be interrupted without considering the
connection to be permanently broken.  A value of zero
indicates no preference on behalf of the application, and
that the underlying service provider's default value should
be used.

iQualOfGuarantee

This field corresponds to the Quality of Guarantee field in
the RFC.  It is expected that the internetwork will likely
have to offer more than one type of guarantee.  There are
two unrelated issues related to guarantees.

First, it may not be possible for the internetwork to make a
firm guarantee.  Consider a path through an internetwork in
which the last hop is an Ethernet.  Experience has shown
(e.g., some of the IETF conferencing experiments) that an
Ethernet can often give acceptable performance, but clearly
the internetwork cannot guarantee that the Ethernet will not
saturate at some time during a flow's lifetime.  Thus it
must be possible to distinguish between flows which cannot
tolerate the small possibility of a failure (and thus must
guaranteed at every hop in the path) and those that can
tolerate islands of uncertainty.

Second, it is presumed that some applications will be able
to adapt to modest variations in internetwork performance
and that network designers can exploit this flexibility to
allow better network utilization.  In this model, the
internetwork would be allowed to deviate slightly from the
promised flow parameters during periods of load.  This class
of service is called predicted service (to distinguish it
from guaranteed service).

The difference between predicted service and service which
cannot be perfectly guaranteed (e.g., the Ethernet example
mentioned above) is that the imperfect guarantee makes no
statistical promises about how it might misbehave.  In the
worst case, the imperfect guarantee will not work at all,
whereas predicted service will give slightly degraded
service.  Note too that predicted service assumes that the
routers and links in a path all cooperate (to some degree)
whereas an imperfect guarantee states that some routers or
links will not cooperate.

There are six legal values:

  NO_GUARANTEE - no guarantee is required (the host is
  simply expressing desired performance for the flow).

  IMPERFECT_GUARANTEE_REQUESTED - an imperfect guarantee is
  requested.

  PREDICTED_SVC_REQUIRED - predicted service is requested
  and if unavailable, then no flow should be established.

  PREDICTED_SVC_REQUESTED - predicted service is requested
  but an imperfect guarantee is acceptable.

  GUARANTEED_SVC_REQUIRED - guaranteed service is requested
  and if a firm guarantee cannot be given, then no flow
  should be established.

  GUARANTEED_SVC_REQUESTED - guaranteed service is
  requested and but an imperfect guarantee is acceptable.

Application developers should realize that asking for
predicted service or permitting an imperfect guarantee will
substantially increase the chance that a flow request will
be accepted.

iFlowContent

This field represents an extension over the flow spec
defined in the RFC.  The allowed values are all manifest
constants which indicate the type of media being transported
over the flow.  Use of this field is optional.  Its purpose is
to provide a simplified alternative to specifying QOS
parametrically.  For service providers that are "tuned" to
transport certain types of media, merely identifying the socket
as bearing a reconginzed media type may be sufficient to
identify needed QOS levels.

Currently defined values include
  UNSPECIFIED
  GSM_AUDIO
  ADPCM_AUDIO
  (TBD other types of audio streams)
  INDEO_PRV
  INDEO_ISV
  INDEO_MRV
  H261
  MPEG1
  MPEG2
  (TBD other types of video stream)
  SVC_PROVIDER_SPECIFIC - service providers are free to
  define their own constants for media streams with values
  greater than or equal to this.

iCostSensitivity

This field represents an extension over the flow spec
defined in the RFC.  The allowed values are manifest
constants which indicate whether or not the application
wishes to minimize any costs associated with a connection to
the possible detriment of other QOS parameters.  Allowed
values are:

  NOT_COST_SENSITIVE - the application considers cost to be
  a secondary concern or no concern at all.

  COST_SENSITIVE - the application considers cost to be a
  primary concern and wishes to minimize it where possible.

iEncryptionSel and lpEncryptionKey

These fields represents an extension over the flow spec
defined in the RFC.  They are used to indicate the
application's choice for encryption algorithms (if any) and
also to specify a pointer to where an encryption key may be
found.  Interpretation of the memory contents pointed to by
the encryption key pointer is service provider/encryption
algorithm specific.  Values for the iEncryptionSel field are
also service provider specific, with the convention that
zero is used to indicate that no encryption is being
requested.

Default Flow Spec

A default flow spec is associated with each eligible socket
at the time it is created.  Field values for this default
flow spec are indicated below.  In all cases these values
indicate that no particular flow characteristics are being
requested from the network.  Applications only need to
modify values for those fields that they are interested in,
but must be aware that there exists some coupling between
fields as was described above.

iMaxMsgSize =       SO_MAX_DG_SIZE for the particular service provider
fAvgBw =                0, no bandwidth request
fBurstLength =      0, not applicable because fAvgBw is zero
fBurstRate =        0, not applicable because fAvgBw is zero
fMinLinkSpeed =     supplied by network, undefined until connection occurs
iConnectionStatus=  supplied by network, undefined until connection occurs
iMinDelaySel =      NO_DELAY_SENSITIVITY
fMinDelayValue =    0, not applicable
fMaxDelayVariation =0, not applicable
iLossSensitivity =  NO_LOSS_SENSITIVITY
fMaxLostPkts =      0, not applicable
fLossInterval =     0, not applicable
iMaxSvcOutage =     0, use provider defaults for time-out
iQualOfGuarantee =  NO_GUARANTEE
iFlowContent =      UNSPECIFIED
iCostSensitivity =  NOT_COST_SENSITIVE
iEncryptionSel =    0, no encryption requested
lpEncryptionKey =   NULL


The semantics for associating a flow spec with a socket or
socket group appeared as part of our proposed extension #7
on socket groups.  The WSAConnectEx() function which was
described therein is used.  For the sake of completeness, we
repeat that function description here.

int PASCAL FAR WSAConnectEx ( SOCKET s, const struct sockaddr FAR * name,
          int namelen, GROUP g, char  FAR * lpSFlowspec, int iSFlowspecLen,
          char FAR * lpGFlowspec, int iGFlowspecLen );

          s          A descriptor identifying an unconnected
                    socket.

          name      The name of the peer to which the socket
                    is to be connected.

          namelen   The length of the name.

          g         The identifier of the socket group.

          lpSFlowspec    A pointer to the flow spec for
                    socket s.

          iSFlowspecLen  The length of the flow spec for
                    socket s.  It must be larger than or
                    equal to the size of struct FLOWSPEC.

          lpGFlowspec    A pointer to the flow spec for the
                    socket group to be created, if the value
                    of parameter g is SG_CONSTRAINED_GROUP.

          iGFlowspecLen  The length of the flow spec for the
                    socket group to be created, if the value
                    of parameter g is SG_CONSTRAINED_GROUP.
                    It must be larger than or equal to the
                    size of struct FLOWSPEC.

          This function is used to create a connection to
          the specified destination.  For connection-
          oriented sockets (e.g., type SOCK_STREAM), an
          active connection is initiated to the foreign host
          using name (an address in the name space of the
          socket;).  When the socket call completes
          successfully, the socket is ready to send/receive
          data.

          For a connectionless socket (e.g., type
          SOCK_UNREL_DGRAM), the operation performed by
          WSAConnectEx() is merely to establish a default
          destination address which will be used on
          subsequent send() and recv() calls.

          If the socket, s, is unbound, unique values are
          assigned to the local association by the system,
          and the socket is marked as bound.  Note that if
          the address field of the name structure is all
          zeroes, WSAConnectEx() will return the error
          WSAEADDRNOTAVAIL.

          Parameter g is used to indicate the appropriate
          actions on socket groups:
           if g is an existing socket group id, add s to
                         this group, provided all the requirements
                         set by this group are met; or

           if g = SG_UNCONSTRAINED_GROUP, create an
                          unconstrained socket group and have
                          s as the first member; or

           if g = SG_CONSTRAINED_GROUP, create a
                          constrained socket group and have s as
                          the first member; or

           if g = NULL, no group operation is performed.

          For an unconstrained group, any set of sockets may
          be grouped together as long as they are supported
          by a single Service Provider and are connection-
          oriented.  A constrained socket group requires
          that connections on all grouped sockets be to the
          same host.  For newly created socket groups, the
          new group id can be retrieved by using
          getsockopt() with option SO_GROUP_ID, if this
          connect operation completes successfully.

          lpSFlowspec, and iSFlowspecLen specify a block of
          memory containing the flow spec for socket s, if s
          is unidirectional and a DSTREAM type socket.
          Otherwise, these values are ignored.  The first
          part of this memory block is struct FLOWSPEC,
          followed by any Service Provider specific data.
          Thus, iSFlowspecLen must be larger than or equal
          to the size of struct FLOWSPEC.  A NULL value for
          lpSFlowspec indicates no application supplied flow
          spec.

          lpGFlowspec, and iGFlowspecLen specify a block of
          memory containing the flow spec for the socket
          group to be created, if (and only if) the value of
          parameter g is SG_CONSTRAINED_GROUP.  Otherwise,
          these values are ignored.  The first part of this
          memory block is struct FLOWSPEC, followed by any
          Service Provider specific data.  Thus,
          iGFlowspecLen must be larger than or equal to the
          size of struct FLOWSPEC.  A NULL value for
          lpGFlowspec indicates no application supplied flow
          spec.

The QOS notification mechanism utilizes the existing
WSAAsyncSelect() and proposed WSACallbackSelect() functions
by defining an additional event: FD_QOS.  If an application
expresses an interest in being notified about QOS events,
the service provider will utilize the available mechanisms
to notify the app whenever something in the flow spec has
changed.

An application may access the flow spec associated with a
socket or with the socket's group (if any) by retrieving the
value of one of the following proposed get-only socket
options: SO_FLOWSPEC or SO_GROUP_FLOWSPEC.  A returned value
of NULL indicates that there is no associated flow spec.

------------- End of Submittal #8  -----------------------------

????
????
From ormail.intel.com!intelhf.intel.com!ccm!david_b_andersen Fri Feb 18
13:32:51 1994
Date: Fri, 18 Feb 94 13:39:17 PST
From: David B Andersen <[e-mail]>
Message-ID: <[e-mail]>
To: [e-mail]
cc: [e-mail], [e-mail]
Subject: Input for Winsock Ver 2
Status: OR


Text item: Text_1

                                                    02/18/94
Dear Martin,

Intel is pleased to supply the following input to the Winsock 2
definition process. There are 10 proposals in all, with this submittal
corresponding to proposal number 9.

For each of our proposals we supply a desciption of the proposed
extension, our motivations for making the extension proposal, and the
detailed syntax for how the extension might be implemented.

We would also like to volunteer our services to assist in the process
of collating and summarizing the various submitals that are coming in
from Forum members.  Please let us know how we can best assist you in
this process.

Regards,

David B. Andersen
Intel Architecture Labs


Extension #9:
     Conditional acceptance of socket connection requests

Description:
The current Winsock specification does not provide a way for
an application with a listening socket to conditionally
accept an incoming connection request based upon the
requester's address.  (In other words, Winsock has no
equivalence to caller ID.)  This is curious since the
current Winsock spec includes an error code for the
connect() function which indicates that the connection
attempt was rejected, but does not provide a mechanism that
allows a listening application to cause this rejection to
occur.  Currently, the only viable option is for the
listening app to accept the connection, use getpeername() to
establish the caller's ID and then immediately close the
socket.  The caller may well begin sending as soon as the
connection is accepted, and will probably not understand why
the connection was suddenly closed.

We propose to remedy this by making it possible for an
application to discover who is wanting to connect prior to
accepting the request, and by allowing the app to reject the
request if it decides to.

Motivation:
Most other transport level interfaces have such a feature.
It's usefulness is, I think, obvious.

Semantics:
In our proposed extension #7 on socket groups we introduced
the proposed WSAAcceptEx() function as a means to performing
grouping of sockets.  This same function is also used for
conditional acceptance.  The basic approach is to allow the
app to specify a conditional acceptance function that is
called incident to the invocation of WSAAcceptEx().  The
inbound parameter  identifies the address of the requester.
The return value indicates whether the connection is to be
accepted or rejected.  As noted previously, the application
may also utilize this function to establish the new socket
as a group member.  We repeat the syntax for the
WSAAcceptEx() function below:

SOCKET PASCAL FAR WSAAcceptEx ( SOCKET s, struct sockaddr
          FAR * addr, int FAR * addrlen, FARPROC lpfnCondition );

          s          A descriptor identifying a socket which
                    is listening for connections after a
                    listen().

          addr      An optional pointer to a buffer which
                    receives the address of the connecting
                    entity, as known to the communications
                    layer.  The exact format of the addr
                    argument is determined by the address
                    family established when the socket was
                    created.

          addrlen   An optional pointer to an integer which
                    contains the length of the address addr.

          lpfnCondition  The procedure instance address of
                    the application-supplied condition
                    function which will make an
                    accept/reject decision based on the
                    caller information passed in as
                    parameters, and optionally create and/or
                    join a socket group by assigning
                    appropriate value to the result
                    parameter g of this function.

          This routine extracts the first connection on the
          queue of pending connections on s, and checks it
          against the condition function.  If the condition
          function returns TRUE, this routine creates a new
          socket with the same properties as s and returns a
          handle to the new socket, and then optionally
          creates and/or joins a socket group based on the
          value of the result parameter g.  Otherwise,
          reject this connection request, and proceed to the
          next one.  If no pending connections are present
          on the queue, and the socket is not marked as non-
          blocking, WSAAcceptEx() blocks the caller until a
          connection is present.  If the socket is marked
          non-blocking and no pending connections are
          present on the queue, WSAAcceptEx() returns an
          error as described below.  The accepted socket may
          not be used to accept more connections.  The
          original socket remains open.

          The prototype of the condition function is as
          follows:

       BOOL PASCAL FAR ConditionFunc( const char FAR
          * caller, int callerlen, GROUP FAR * g);

          ConditionFunc is a place holder for the
          application-supplied function name.  The actual
          condition function must reside in a DLL or
          application module and be exported in the module
          definition file.  You must use MakeProcInstance()
          to get a procedure-instance address for the
          callback function.  The exact format of the caller
          parameter is determined by the address family in
          which the communication is occurring.

          The result parameter g is assigned within the
          condition function to indicate the following
          actions:
               if g is an existing socket group id, add s to
          this group, provided all the requirements
           set by this group are met; or

          if g = SG_UNCONSTRAINED_GROUP, create an
                         unconstrained socket group and have
                         s as the first member; or

          if g = SG_CONSTRAINED_GROUP, create a constrained
                          socket group and have s as the first member; or

          if g = NULL, no group operation is performed.

          For unconstrained groups, any set of sockets may
          be grouped together as long as they are supported
          by a single Winsock Service Provider and are
          connection-oriented.  A constrained socket group
          requires that connections on all grouped sockets
          be to the same host.  For newly created socket
          groups, the new group id can be retrieved by using
          getsockopt() with option SO_GROUP_ID, if this
          connection operation completes successfully.

          The argument addr is a result parameter that is
          filled in with the address of the connecting
          entity, as known to the communications layer.  The
          exact format of the addr parameter is determined
          by the address family in which the communication
          is occurring.  The addrlen is a value-result
          parameter; it should initially contain the amount
          of space pointed to by addr; on return it will
          contain the actual length (in bytes) of the
          address returned.  This call is used with
          connection-oriented socket types such as
          SOCK_STREAM.  If addr and/or addrlen are equal to
          NULL, then no information about the remote address
          of the accepted socket is returned.


????
????
From ormail.intel.com!intelhf.intel.com!ccm!david_b_andersen Fri Feb 18
13:55:06 1994
Date: Fri, 18 Feb 94 13:45:15 PST
From: David B Andersen <[e-mail]>
Message-ID: <[e-mail]>
To: [e-mail]
cc: [e-mail], [e-mail]
Subject: Input for Winsock Ver 2
Status: OR


Text item: Text_1

                                                    02/18/94
Dear Martin,

Intel is pleased to supply the following input to the Winsock 2
definition process. There are 10 proposals in all, with this submittal
corresponding to proposal number 10. (Finally!)



Regards,

David B. Andersen
Intel Architecture Labs



Extension #10:
     Integration hooks for Windows Telephony

Description:
One of the primary benefits in extending Winsock to cover
multiple transports will be in providing a uniform and
consistent way to access to the data transport capabilities
of telephony connections, particularly high-bandwidth,
digital telephony.  In order to achieve this we believe it
is essential that Winsock work smoothly with the Windows
Telephony API (TAPI).  As both APIs are built upon the
Windows Open Systems Architecture (WOSA) foundation, we
assume at the outset that the best interworking will be
achieved when a single driver acts simultaneously as both a
Winsock and TAPI service provider.

There are several capabilities which are key to facilitating
this close interworking between call control and data
transmission.  Foremost among these is the ability for
applications to utilize telephony networks without needing
to be explicitly aware that they are doing so.  Winsock
should be able to accommodate this by providing a uniform
data transport abstraction that is common and consistent
across all supported networks.  Winsock service providers
should implement for telephony networks the multiplexing
capability that is expected and required on packet switched
networks.  Secondly, a method is needed to transition back
and forth between controlling a call with TAPI and
transmitting data with Winsock.  These capabilities can be
expressed by adding two additional socket options for
accessing underlying TAPI-specific identifiers.

Motivation:
Ever since the earliest days of SLIP and on into the present
with PPP, there has never been a standardized way to
establish an underlying telephone call.  When a protocol
such as TCP/IP or NetBIOS is to be run over a telephony
connection, the native addressing format of the protocol has
no way to include the required phone number.  In these
instances, the application will frequently need to establish
the connection itself prior to initiating data
communications.  The proper interface to use for this is
TAPI, since that is what it was made for.

Other  protocols are designed specifically for telephony
connections and their notion of address includes the phone
number.  When using such a protocol, the application need
not be concerned with pre-establishing the telephony
connection, as the service provider will have all of the
information needed to establish the connection itself.
However, even under these circumstances, we don't want to
preclude the application from being able to exercise control
over the underlying call.  Thus providing a way to go from a
Winsock data connection to the underlying TAPI call and back
again would be both powerful and useful.

Semantics:

Creating Winsock Sockets on an Existing Call

TAPI contains a function lineGetID that, given a line,
address, or call allows the app to find the companion
service-specific device name corresponding with the call.
For example, lineGetID can be invoked on an existing TAPI
call (using its handle) requesting the Winsock "device name"
corresponding to the given call.  If the TAPI provider does
not support Winsock , an error is returned.  Otherwise, a
Winsock "device name" is returned.

          #include "tapi.h"

          LPVARSTRING    lpDeviceID;
          HCALL          hCall;
          int                    Size_of_POTS;

          Size_of_POTS = sizeof(int) + sizeof(POTS_Address);
          lpDeviceID = Any-Memory-Allocation-Function (
                                        sizeof(VARSTRING) + Size_of_POTS );
          lpDeviceID->dwTotalSize = sizeof(VARSTRING) + Size_of_POTS;
          lineGetID( 0, 0, hCall,
          LINECALLSELECT_CALL,lpDeviceID, "Winsock");

What is actually returned in the VARSTRING struct pointed to
by the lpDeviceId parameter is the information that an
application using Winsock would need to create one or more
sockets over an existing phone call: namely a valid Winsock
address family and the remote address itself.  With this
information, the application can create a socket of the
desired type and request that a connection be established.

          #include "Winsock.h"

          SOCKET    s;
          void FAR *     lpDest_address;

          lpDest_address = lpDeviceID + lpDeviceID->dwStringOffset;
          s = socket( (int)*lpDest_address, SOCK_UNREL_ISOCH_STREAM, 0 );
          connect( s, lpDest_address, &Size_of_POTS );
          // Now, you can use Winsock as appropriate.

The underlying service provider will realize that a new call
does not need to be placed and simply create the required
data stream.


Transitioning a Call From Winsock to TAPI

In transitioning from a data transmission mode to a call
control mode, the application is strongly advised to first
use shutdown() to gracefully terminate the existing data
traffic without causing the underlying resources (i.e. the
phone call) to be released.  Once this is done the
application can retrieve the values of  PVD_CALL_ID which is
a "Call ID" assigned by the Service Provider (SP)
corresponding to the underlying call, and TAPI_DEVICE_ID
which is a TAPI device ID for the line over which the call
was placed.  Having obtained the information, the
application is then ready to invoke appropriate TAPI
functions in order to find the appropriate call handle as
follows and manipulate the call thereafter.

          #include "Winsock.h"
          #include "tapi.h"

          SOCKET    s;
          DWORD          dwCallID;      // Call ID defined by SP
          DWORD          dwDeviceID;    // TAPI line device ID
          LPHLINEAPI     lphLineApp;
          LPHLINE                lphLine;
          LPLINECALLLIST lpCallList;

          // A connection associated with socket s has been set up,
          // and some data may have been transferred over it using
          // Winsock.  Now, we would like to retrieve and  manipulate the
          // underlying TAPI call.

          shutdown( s, SD_BOTH );
          getsockopt( s, SOL_PROVIDER, PVD_CALL_ID, &dwCallID,
&sizeof(DWORD));
          getsockopt( s, SOL_PROVIDER, TAPI_DEVICE_ID, &dwDeviceID,
                                          &sizeof(DWORD));
          lineInitialize(lphLineApp, ... );
          lineOpen(*lphLineApp, dwDeviceID, lphLine, ... );
          // Here, allocate appropriate memory for the Call List
          // pointed to by lpCallList.
          lineGetNewCalls(*lphLine, 0, LINECALLSELECT_LINE, lpCallList);
          // Search for the list to find the matching hCall which has
          // the same "Call ID" (obtained by using lineGetID() with
          // "WINSOCK" device class, as shown above) as the dwCallID
          // returned from getsockopt() earlier.

          // Now, you can use TAPI to manipulate hCall as appropriate.


Transitioning a Call Back to Winsock from TAPI

If the application wishes to resume data communications on a
call that has been manipulated with TAPI, it is advisable to
assume that all existing sockets in the shutdown state are,
in some sense, broken.  Therefore, the application should
first use socket() to create replacement sockets, and then
use closesocket() to eliminate all sockets that were left in
the shutdown state.  Eliminating all of the old sockets
first is not wise as this will likely cause the underlying
phone call to be dropped.

          #include "Winsock.h"

          SOCKET        old_s, new_s;
          VOID FAR *     name;
          int FAR *              namelen;

          new_s = socket( AF_POTS, SOCK_UNREL_ISOCH_STREAM, 0 );
          getsockname( old_s, name, namelen );
          closesocket( old_s );
          bind( new_s, name, namelen);
          // Now, use lineGetID() to get the (maybe new) destination
          // address, and reconnect using connect() as shown above


????


-------------------------------------------------------------------------
Martin Hall                         108 Whispering Pines Drive, Suite 115
JSB Corporation                     Scotts Valley, California 95066
[e-mail]                   Tel: [phone]   Fax: [phone]

From: rcq
To: martinh
Cc: towfiq; davidtr
Subject: Windows Sockets 2 Contribution
Date: Sunday, March 06, 1994 7:22PM

Return-Path: <netmail![e-mail]>
Date: Sun, 6 Mar 94 19:22:35 EST
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Windows Sockets 2 Contribution
From: netmail![e-mail]  (Bob Quinn)
Reply-To: netmail![e-mail]
Cc: [e-mail], [e-mail]
Sender: netmail![e-mail]
Repository: mailserv-D.ftp.com, [message accepted at Sun Mar  6 19:22:11 1994]
Originating-Client: aeolus.ftp.com
Content-Length: 17903
------------------------------------------------------------------------------
Gentlemen:

I apologize for this very late entry.  Unfortunately, the delay
couldn't be avoided.  I hope these suggestions can still be
considered.

I have forwarded this one file with all my suggestions to all three
of you.  And I forwarded individual messages for each of these
items to Martin, as he requested in his original solicitation.

Thanks for your consideration,
--
 Bob Quinn                                             [e-mail]
 FTP Software, Inc.                                No. Andover, MA

Version 2.0 Windows Sockets suggested improvements
--------------------------------------------------
The following file contains numbered suggestions for Version 2.0
of the Windows Sockets specification in the format requested by
Martin Hall (e.g. one line summary, followed by a single paragraph
description).  The order in which they appear is arbitrary (i.e.
NOT related to their priority).
--
(1)Summary: Allow optional support of Windows Sockets extensions and
        add a new function to return bit flags to indicate which
        optional features a WinSock implementation supports.

Description:
The Windows Sockets API should use The Hosts Requirements RFC 1122
as a model for differentiating between required and optional features.
Since it is an API, not a protocol specification, the WinSock spec
can go one step further to provide a mechanism for reporting on the
optional features supported (e.g. a function GetWinsockExtensions()
that returns a pointer to bitflags defined by the Windows Sockets
specification to denote different extensions).

--
(2) Summary: Add ability to support larger IP address space as needed
        by Simple Internet Protocol (IPng contender).

Description:
SIPP is one of the contenders the IETF is considering for IP "Next
Generation" (IPng).  "In order to implement the Simple Internet
Protocol (SIPP) [Deering, ietf-draft, Nov'92] in an operating system
based on 4.x BSD, changes must be made to some of the application
program interfaces (APIs)...This paper presents a first attempt to
define the API changes needed to support SIPP in BSD systems."  The
primary change the API must deal with is an increase in the size of
an IP address from 4-bytes to 8-bytes.

  from SIPP API Specification (draft-ietf-sip-bsd-api-01.txt)
  12/20/93 by Richard E. Gilligan ([e-mail])

Summary of new additions:
-------------------------
/* Simple Internet Protocol Address Form in use (NOT a socket type) */
    #define AF_SIPP     24

/* If AF_SIFF, sockaddr_in fields are redefined by macros */
        #define sipp_addr       sin_zero
        #define sipp_zero       sin_addr

/* sockets passed between processes use setsockopt() to set addr form */
        #define SIPP_ADDRFORM   0x16

/* setsockopt() to set flow ID in SIPP packets sent (cannot getsockopt()
    on received SIPP packets, however) */
        #define SIPP_FLOWID     0x15

/* new gethostbyname() equivalent for SIPP addresses */
        struct hostent *hostname2addr(const char *name, int af,
                                        char *buf, int buflen);

/* new ascii2addr() and addr2ascii() for SIPP address input/output */
        int ascii2addr(long af, char *cp, char *ap);
        char *addr2ascii(long af, char *ap, char *buf, int buflen);

--
(3) Summary: Allow retrieval of local IP address without using name
        resolution.

Description:
Allow support for the BSD gethostid() function, as well as the
SIOCGIFADDR option for the ioctlsocket() function.  For multi-homed
stacks, SIOCSIFADDR should also be allowed (to set local IP address).

--
(4) Summary: Provide access to the broadcast address.

Description:
Define support for the ioctlsocket() options SIOCGIFBRDADDR and
SIOCSIFBRDADDR to get and set the IP Broadcast address.

--
(5) Summary:  Provide the Address Resolution Protocol (ARP) table.

Description:
Allow support for the SIOCGARP, SIOCSARP and SIOCDARP ioctlsocket()
options to get, set and delete entries in the TCP/IP protocol stack's
ARP table.

--
(6) Summary: Allow all low-level interface ioctlsocket() options to
        provide full control to an application on multi-homed hosts.

Description:
The following ioctlsocket() options should be (optionally) supported:
  - SIOCGIFADDR and SIOCSIFADDR ioctlsocket() options to get and set
     the interface address.
  - SIOCGIFDSTADDR and SIOCSIFDSTADDR to get and set point-to-point
     interface address.
  - SIOCGIFFLAGS and SIOCSIFFLAGS to get and set interface flags
     (which indicate, for example, if the interface is point-to-point,
     supports broadcast addressing, whether the interface is running...
  - SIOCGIFCONF to get the interface configuration list containing one
     ifreq structure (a la BSD) for every interface available.
  - SIOCGIFMETRIC and SIOCSIFMETRIC to get and set the routing metrics
     (the kernel routing tables).

--
(7) Summary: Allow direct manipulation of the TCP Window.

Description:
Define (optional) support of the following:
  - SIOCGHIWAT and SIOCSHIWAT ioctlsocket() options to get and set
     the TCP Window High Water mark.
  - SIOCGLOWAT and SIOCSLOWAT ioctlsocket() options to get and set
     the TCP Window Low Water mark.
  - SO_RCVLOWAT and SO_SNDLOWAT setsockopt() options to get and set
     the send and recieve low water marks.

--
(8) Summary: Define support for multicast using explicit binding (with
        the bind() function).

Description:
Any UDP Socket can send a datagram to a multicast address, but to
receive a multicast packet the socket must be (explicitly) bound to
the multicast address.  The underlying stack should do the right
thing to register the multicast address (e.g. using IGMP according
to Hosts Requirements RFC1122).

--
(9) Summary: Define a mechanism that would optionally prevent re-
        entrant messages to an application while a function (blocking
        or non-blocking) is pending.

Description:
Currently there is no blocking hook strategy that will prevent
reentrant messages to a calling application and work with all Windows
Sockets implementations available.  Since there are many applications
and DLLs in existence that need network access but cannot be rewritten
to handle reentrant messages, a caller should not be required to handle
re-entrant messages while a network operation is pending.  A blocking
hook function that prevents reentrant messages should be possible on
all WinSock DLL implementations.

--
(10) Summary: As long as every process registers with a Winsock DLL,
        it should be able to access the sockets of another process.

Description:
Optional socket sharing between tasks can be implemented in one of two
ways: explicit or implicit.  Implicit sharing would allow any taskt that
calls WSAStartup() to to use any socket available.  Explicit sharing (as
in OS/2) would require a task to call ExportSocket(s) to make a socket
sharable and any task that wanted to use exported sockets would need to
call ImportSocket().  Either method is sufficient and necessary to
facilitate creation of many intermediate API's ("middleware") and master
server applications (that spawn other server applications, e.g. inetd).

In addition, this new socket sharing ability will require new function
definitions to provide information on a per socket basis.  Specifically:
   - WSAGetLastSocketError() to get the last error for an individual
      socket (whereas WSAGetLastError() is task-based).
   - WSAIsSocketBlocking() to determine if an individual socket has
      a blocking operation pending.
   - WSACancelSocketBlocking() to cancel an individual blocking socket.
Another possible strategy might be to leave the current two functions
and add a setsockopt() option to select a particular socket for these
functions to report on.

The task that creates a socket "owns" the socket.  When that task calls
WSACleanup() the WinSock DLL should destroy the socket, whether or not
the application called closesocket().  Subsequent calls by other tasks
that reference that socket should fail with WSAENOTSOCK.

--
(11) Summary: Action of the WinSock DLL and underlying stack after a
        non-blocking closesocket() call needs clarification.

Description:
When an application calls closesocket() with a non-blocking socket:
  - a WinSock DLL should also fail with WSAEWOULDBLOCK on a non-
     blocking socket without SO_LINGER set (currently the specification
     only says it should with a non-zero SO_LINGER setting)
  - the specification should determine a default timeout for closing
     a socket (e.g. a default time period after which the WinSock DLL
     or underlying stack assumes the other end is not going to respond
     to the TCP <FIN>, sends a <RST> and releases resources.
  - the specification should also specify whether an application should
     call closesocket() a second time after it returns a WSAEWOULDBLOCK
     error, or use some other means to determine the state of the socket
     (e.g. select() or asynch message).
  - the specification should determine whether an application should
     call WSACleanup() immediately upon return from a closesocket()
     call that fails with WSACleanup, and describe the action of
     WSACleanup() when this happens (i.e. reset the connection).

--
(12) Summary: Define standard database format, locations, and mechanisms
        for finding and setting them.

Description:
WinSock DLLs should have their (standard BSD format) database files in
a well-known location, there should be a mechanism for locating them
(e.g. getservent(), gethostent(), getprotoent() functions) and setting
them (setservent(), sethostent(), setprotoent() functions).  This would
have the added benefit of allowing sequential search of the file(s) by
an application (creating a function to do so is unnecessary).

--
(13) Summary: Define the C++ Class Library for Windows Sockets

Description:
The Windows Sockets API should have a standard class library defined
that takes advantages of OOP encapsulation features with some
specialized classes that make programming to the specification easier
(e.g. TCP server, TCP client, etcetera).

--
(14) Summmary: Define the standard Error Text for WinSock errors

Description:
Use the BSD 4.3 descriptions for analogous errors in English.  Provide
the source code for one possible function that uses string resources
to translate error numbers into text, but put the onus on the applica-
tion developer to implement the function and provide the text (so they
can translate into other languages if they want to).

--
(15) Summary: Statements needed on some issues

Description:
The specification should make statements to clarify the assumptions
an application developer can make in regards to:
    - assuming a socket is equivalent to a file descriptor
    - socket sharing between processes
    - database file (host table, protocol and services file)
       format and location
    - name resolution protocols used
    - support of the Unix Domain, the loopback addresses, and
       recommendations for local interprocess communication in
       Windows
    - recommended ways to retrieve local username.
    - caution application developers not to do more than one recv()
       call in their FD_READ message handler (a common mistake).

--
(16) Summary: Define support for protocols other than TCP/IP

Description:
At a minimum, describe support for NetBEUI, IPX/SPX and Appletalk.

--
(17) Summary: Define a standard debugging paradigm

Description:
Current support of setsockopt(SO_DEBUG) option is spotty at best,
and undefined (so it differs between winsock implementations).  The
specification should make recommendations on the mechanism to use
for output and the format of the output.  The Windows Debug device
is an obvious candidate, though it is very crude since it doesn't
provide a means of filtering output and can be overloaded.  Defining
a DDE or OLE interface would be more elegant and useful.

--
(18) Summary: Define a mechanism for handling multiple Winsock DLL's
        simultaneously.

Description:
With the support of protocol suites in addition to TCP/IP, users are
likely to need more than one WinSock DLL in use simultaneously.  The
Windows Sockets specification must define a mechanism for multiplexing
co-resident Windows Sockets API's.  Microsoft's Service Provider
Interface (SPI) seems a likely candidate.

--
(19) Summary: Define a standard mechanism for determining the version
         of the WinSock DLL implementation itself

Description:
Require the use of the standard Version Resource or add a field to
WSAData so a program can retrieve a numeric version description in a
standard way.

--
(20) Summary: Define a mechanism to allow access to the subnet mask.

Description:
Define the use of the ioctlsocket() options SIOCGIFNETMASK and
SIOCSIFNETMASK to get and set the IP subnet address mask.

--
(21) Summary: Provide a mechanism to allow access to the IP routing.

Description:
Define the use of the ioctlsocket() options SIOCADDRT and SIODELRT
to add and delete an IP route.

--
(22) Summary: Provide for asymmetric send and receive Maximum UDP
        datagram sizes.

Description:
Currently there is only one iMaxUdpDg (maximum UDP Datagram size) in
the WSAData structure returned by WSAStartup().  Since outgoing
datagrams do not make large buffer demands, but incoming oversized
datagrams do, some TCP/IP protocol stacks can send oversized Datagrams
but cannot receive them.  Just as there is symmetry with send and
receive buffer sizes (SO_SEND and SO_RECV options for setsockopt),
there should be symmetry for iMaxUdpDg to differentiate the max UDP
datagram sizes that an application can send and receive.

--
(23) Summary: Provide a mechanism to set the Time-to-Live field in
        an IP packet.

Description:
In BSD the only way to get at the IP Time-To-Live (TTL) field is to
request a SOCK_RAW socket for IPPROTO_IP, and create the IP header in
it's entirety.  Since many TCP/IP stacks cannot provide this service
and because it invites disaster, this is not ideal.  Setting the TTL
is very useful for providing a simple mechanism to do the typical
(UDP or ICMP) traceroute function. The spec should define a simple
mechanism such as a SO_TTL option for setsockopt() that would allow
setting the TTL without wreaking havoc.

--
(24) Summary: Provide a mechanism to get a "privileged port"

Description:
Provide the function rresvport(), to return a port number between
512 and 1024.

--
(25) Summary: Provide API support for gather reads and scatter writes.

Description:
Provide (equivalents for) the functions readv() and writev().

--
(26) Summary: Provide a symmetrical function to gethostname() to allow
        setting a local hostname.

Description:
Define a new function sethostname().

--
(27) Summary: Define a mechanism to retrieve network statistics

Description:
There are many times when an application needs access to network stack
statistics (such as when implementing an network management station,
for example).  There should be a function that provide statistics akin
to those returned by BSD netstat.  This function could return a pointer
to a network domain specific statistics structure that had counts of
protocol packets in/out, error counts, etcetera.

--
(28) Summary: Define how the Windows Sockets API expects the TCP/IP
        stack to implement out of band data (urgent data).

Description:
Describe the fact that OOB data is *not* truly "out of band" (i.e.
that it cannot be retrieved until all data previous to it has
been processed).   The reason for this limitation is that a TCP urgent
pointer can point ahead to data that the stack hasn't received yet.
The specification should provide the semantics --preferably as an
example--of how OOB should be used when "in-line" and not.

--
(29) Summary: Each function should have a simple sample to show how
        to use it.

Description:
A sample is worth a thousand words.  Many functions warrant more
than one example to show the different ways to use a them, but
the samples don't need to cover all possible variations (just some
of the common ones, and particularly those that cause confusion).

--
(30) Summary: Provide a mechanism for setting the TCP push bit.

Description:
Add an option flag for send() that allows setting the TCP push bit
since some TCP/IP stacks require receipt of a TCP segment with the
push bit set before data will be made available to the application.
Another possibility is to adopt the flush() function used in BSD.
NOTE: This is not related to the TCP_NODELAY setsockopt() option
which overrides the Nagle algorithm.

--
(31) Summary: Add an option to turn off UDP checksumming

Description:
Many new applications are doing transmission of multi-media (e.g.
video and audio) and typically they use UDP.  Some applications may
be tolerant of errors in the data received and might prefer to
receive damaged data over the alternative of not receiving the data
at all.  Adding a setsockopt() option to disable UDP checksumming
(which is optional as per The hosts requirements RFC1122), would
allow this possibility.

--
(32) Summary: When an FD_READ message contains an error, don't
        require the application to call the notification reenabling
        function (recv() or recvfrom()).

Description:
One very common error in Windows Sockets application programming is
not to call recv() or recvfrom() when an error is passed in an FD_READ
message.  Subsequently, the WinSock DLL will not send anymore FD_READ
messages, though there may in fact be data pending.  Since errors are
infrequent, it should not cause problems if the FD_READ event is "edge
triggered" for messages containing errors.  In other words, after a
WinSock DLL sends an FD_READ message containing an error, it should
post subsequent FD_READ messages even if the application hasn't called
either recv() or recvfrom() (the "notification re-enabling functions").

--
(33) Summary: SOCK_RAW useage should be defined.

Description:
At a minimum, the use of SOCK_RAW for IPPROTO_ICMP should be defined.